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Abstract 


This thesis presents formal specification and’ verification techniques for both serial 
and parallel programs written in SIMULA-like ob ject oriented languages. 

These techniques are based on the notion of states of individual ob jects which are 
defined uniformly in serial and parallel computations. They can specify and verify the 
behavior of data and procedural objects in multi-process environments, thus overcoming 
some of the difficulties in dealing with parallelism which characterized previous work on 
formal specifications for abstract data types. Among others, the specif ications and 
verifications of a bounded buffer and air line reservation systems are given. 

Using a model of a simple post office, we illustrate our specification and 
verification techniques for systems, such as operating systems and multi-user data base 
systems, which are characterized by complex internal concurrent activities. It is 
demonstrated that the specifications of the overatt functions of the system which we call 
task specifications can be dertved from: specifications of the” individual behavior and 
mutual interaction of the subsystems. 

A method of defining states of individual objects as mathematical functions is: 
suggested. ‘ — 
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1. Introduction 


1.1 Formal Specifications and Verifications 


A program specification is a description of the desired program behavior. It is 
necessary to specify what task the program is supposed to perform and what effects 
(side-effects) are caused by carrying out the intended task. 

Program specifications can be written in languages of varying degrees of 
formality. Although informal languages, such as natural languages, diagrams, and 
combinations of these, help people to convey intuitive ideas about program behavior, their 
inherent ambiguity is a drawback. In order to rule out the possibility of ambiguous 
interpretations, program specifications should be written in formal languages. When 


formal specifications might be difficult to understand, they may be accompanied by 
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informal descriptions of program behavior. 

Formal specifications play an important role in the construction of reliable 
software. They also provide designers and programmers with an exact communication 
medium for discussing the properties of program modules in various phases of software 
construction, such as initial design and coding. Furthermore, they can be used as 
documentation during the maintenance phase. A formal specification can be viewed as a 
contract which describes the agreements between the implementors of a program module 
and its users. The users of a module rely only on the properties derived from its formal 
specifications, while the implementors need only satisfy the requirements stated in the 
specifications. 

Program verification is the process of proving that a given program 
(implementation) meets its formal specifications. When a program module M is built on a 
collection of submodules, their formal specifications can be used in the verification of M. 
Actual programs (implementations) of the submodules need not be used. 


1.2 A Model of Parallel Computation 


This thesis is concerned with the techniques for formal specification and 
verification of both serial and parallel computations. 

In order to discuss specification and verification techniques, we must clearly define — 
the computation model on which the execution of programs ts bated. The computation 
model used in this thesis is the actor model of computation[Greif-Hewitt75, Hewitt-Baker77), 
which can be roughly characterized as one obtained by generaiizing the computation model 


used in SIMULA-like ob ject-oriented languages! to include parallelism. 

The fundamental objects in our model of computation are actors, which unify 
procedures and data structures. An actor is a potentially active object which becomes active 
when it receives a message. No actor treats other actors as objects to operate on; instead it 
sends messages (which are also actors) to other actors. Actors behave like data or data 
structures as well as functions or procedures. For example, a push-down-stack actor pops 
up and returns its top element when it receives a (pop:) message (if it is not empty), and 
when it receives a (push: e) message, it stores @ as its new top element. A factorial actor 
returns 6 when it receives 3. 

The only activity possible in the model is message passing among actors. More 
than one transmission of messages may take place concurrently, which models parallel 
computations. Since processors and processes can be viewed as actors, multi-processor 
information systems and computer networks are modelled by actor systems. In particular, 
distributed systems” and communicating parallel processes can be easily modelled by actors 

or systems of actors{[Yonezawa-Hewitt77, Hewitt-Baker77]. 
| The concept of an event is fundamental in describing the model of computation 
precisely. An event is the receipt of a message by an actor. A computation is expressed as 
a partially ordered set of events, where the order relation represents the temporal “precedes” 
relation. Unordered events can take place concurrently. Thus the partial order of events 


naturally generalizes serial computations (which are totally ordered sets of events) to parallel 


1. Besides SIMULA-67[Dahl-et-al70], CLU[Schaffert-et-al75], ALPHARD[Wulf-et-al75) and 
SMALL-TALK[Learning-Research-Group76) are examples of such programming 
languages. 

2. Distributed systems are multi-processor information processing systems which do not rely 
on the central shared memory for communication. 
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computations. 


1.3 Local State Approach 


In this thesis, we propose an approach, : called ‘the letal state approach, for 
specif ying the. behavior.of actors (objects). In general, the behavior of ah actor in response 
to a message depends upen the past history of messages received ‘bythe actor. By defining 
the state of an actor A as equivalence classes:en the past. mestage histories of A, we can 
specify the behavior of A in response to a message M in terms of: - 

(1) the state of A before A receives M,, 
(2) a set of mutually concurrent events caused by the event where A recetves M and 
(3) the state of A after A-receives M. . 

Since. we assume, in.the medet-of. computation, that te order of message arrivats 
at the same actor is always total, the state of an actor is always welt-defined in both serial 
and parallel computations. Consequently, the. behavior of an actor in both serial and 
parallel computations. can be specified in.a uniform manner. 

We use the term “local” .to emphasize that our approach does not rely on the 
notions of the global clock and the global state of a: system! The use of -gtobal states is 
often motivated by the use of non-deterministic serias conmputations as the ‘undertying 
semantic model for parallel computations. This leads to counter-intuitive serialization of | 
unrelated concurrent events and a large number of possible cases in analyzing properties of 


1. The global clock is the unique time reference available within the entire system. The 
global state of the system at a given time t (by the global clock) is a vector of the states of 
system components determined at the same timet 
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the system. 

In our approach, the behavior of a system is specified in terms of the individual 
behavior of system components and their mutual interaction. Such behavior and 


interaction are described by the states of the system components determined at their local 


. times. 


1.4 Contributions of the Thesis 


Based on the notion of local states, the work presented. in this thesis has made 


several contributions to the area of program specification and verification. 


(1) Formal specifications of Abstract Data Types with Parallelism and Side-effects 

The importance of abstract data types{Liskov-Zilles74] in the construction of 
reliable software has been recognized and two approaches to the formal specification 
technique for abstract data types, ie. algebraic axiomatic(Zilles74, Spitzen-Wegbreit75, 
Guttag75] and abstract model[Hoare?2, Liskov-Berzins77) approaches, have been proposed. 
Yet none. of the techniques of these approaches are able to deal with parallelism and 


side-effects. These techniques are only applicable to data objects without side-effects and 


they fail to.specify the behavior of data objects which are used in parallel computations 
(multi-process environments). Our specification techniques have overcome these limitations. 
Formal specifications for an air line reservation system and bounded buffers will be given’ 


as illustrations of our techniques. 


(2) Conceptual Representations 
We have developed notational devices called conceptual representations to describe 


the states of individual actors (objects, and data structures) at various levels of abstraction. 
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The use of conceptual representations reinforces the notion of data and procedural ¢ ob jects . 
as abstract entities whose internal structures are hidden. _B separating the states of an 
ob ject from its identity, conceptual representations can express sharing among objects in an 


intuitive, yet rigorous manner. ‘Thus our “specification language | with ifs use of alti taste 
representations has flexible and powerful expressiveness. 


(3) Symbolic Evaluation of Programs written in Object-Oriented Languages 

| Symbolic evaluation is a process which abstractly executes programs on abstract 
data. As the major tool for program verification, we tikve developed’ a method for 
symbolic evaluation of programs written in Siam ob jeoct-oriented languages. Our 
formalism based on conceptual representations enables us to deal with the difficulties due 
to object sharing which often arise in verification of programs written in ob ject-oriented 


languages. 


(4) Specifications of Systems with High Internal Concurrency and Task Specifications 

Little work has been done on: ‘specifying and verifying the behavior of a system 
characterized by complex concurrent activities of its subsystems. Operating systems and 
multi-user data base systems fall into this category. In order to illustrate our techniques f' of 
dealing with such systems, we give a model of a simple post office where a number of 
“customers ‘and mail-collectors are represented as internal concurrent activities. We show 
that the specifications of the over-all functions of such a “system, which we call task 
Specifications, are derived from the specifications of td individual behavior and mutual - 
interaction of its subsystems. 
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1.5 Qutline of the Thesis 


_ Chapter 2 introduces conceptual representations, which are extensively used in the 
work presented in this thesis. The precise syntax of conceptual representations and their 
uses | in writing format ‘specifteations of abstract data types ‘without parallelism and 
side-effects are exemplified. Further, algebraic axiomatic and abstract model approaches to 
the specification of abstract data types are discussed in the light of our approach. (This 
chapter does not use the actor model of computation.) 

Chapter 3 gives a precise account of the actor computation model on which the 
discussion in the subsequent chapters is based. It also describes certain characteristics of the 
behavior of actors which must be considered in the development of specification 
techniques. 

Chapter 4 presents our specification techniques for serial computation. The 
separation of the identities of objects from their states is explained and how this is 
incorporated into our formalism is illustrated before our specification language is 
introduced with examples of formal specifications. Several other approaches to program 
specification are reviewed. . 

Chapter 5 describes our method of symbolic evaluation and illustrates our 
verification techniques for serial computations based on the symbolic evaluation method. 
The application of symbolic evaluation to other domains is also discussed. . 

Chapter 6 extends the specification language introduced in Chapter 4 to cover 
parallel computations and illustrates our techniques for writing formal specifications of 
abstract data types with parallelism and side-effects. The notion of local states of actors 
(ob jects) is discussed in detail'in the beginning of the chapter. 

Chapter 7 presents our verification techniques for parallel computations. The 
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verifications of air fine reservation aysteme and bounded buffers are tMustrated, 

Chapter 8 contains an actor model of a simple post of fice, which is an intuitive 
example of a system with high internal concurrency. We.show that the internal activities of 
the post office meet its task. specifications. 

Chapter 9 makes the concluding remarks and suggests future research. 
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2. Conceptual Representations 


Conceptual representations occupy the central role in the formal specification and 
verification techniques presented in this thesis. In this chapter, we will explain the basic 
idea of conceptual representations by illustrating how specifications of conventional data 
structures are written using conceptual representations. However, as will be seen in the later 
chapters, conceptual representations are used to describe states of actors of a wide variety. 
In the later part of this chapter, existing specification techniques for data structures (data 
types), such as algebraic axiomatic ones, and an abstract model approach, will be discussed 


in relation to the techniques based on conceptual representations. 


2.1 Introduction 


We will use conceptual representations to specify a wide range of data structures at 
various levels of abstraction. The motivation in developing conceptual representations is to 
provide a specification language which serves as a good interface between programmers 
and the computer and also between users and implémentors.° A°“good” interface linguage 
. should allow programmers to easily express and understand their intuitive concept of a data 
structure and how it behaves for various operations. For example, the “language” of 
diagrams using boxes and arrows is a very good language in which people can exchange 
their intuitive ideas about the sharing relationships among objects. However, such a 
language is not rigorous enough for the computer to understand without many hidden 
assumptions. The specification language based on conceptual representations introduced in 
this chapter is rigorous and yet able to express graphical intuitions about data structures. 

Different degrees of awareness about the implementation of a data structure are 
required in the different activities of implementing a system such as the initial design, 
coding, and the subsequent evolution. Conceptual representations are flexible enough to 
express only the details which are important in each activity. As mentioned above, 
conceptual ‘Tepresentations are not confined to specifying data structures. They are used to 
describe states of both procedural and data Ob jects and also used to express views and 
summaries of behaviors of such ob jects. Examples of such conceptual representations will 


be found in en Ste ree) lee: Coenen Band Caen A 
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2.2 Conceptualization of Data Structures 


In this section, we explain syntactic constructs of conceptual representations using 
simple examples. The BNF syntax of conceptual representations is given in Figure 2.1 at 
the end of this section. | 


2.2.1 Keywords and C-packages 


Let us consider a simple data structure, a cell, which contains information that can 
be retrieved and updated. In order to express a cell which has its contents, say 10, we use 
the following notation , 


(CELL (contents: 10)). 


This is a conceptual representation of the cell. When this cell is updated with new 


contents, 12, its conceptual representation becomes 
(CELL (contents: 12)) 


A word “CELL” in the above conceptual representations is an example of the keywords 
which express the conceptual types of data structures. The keywords are always spelled in 
italic capital letters. 

In addition to keywords, another syntactic construct, conceptual packages 
(abbreviated as c-packages)! is used to express more detailed information about data 
structures. A notation “(contents:..)" in the conceptual representations for cells is an example 


of c-packages. C-packages are useful to distinguish conceptually different kinds of 


1. The syntax of c-packages are borrowed from that of packages in PLASMA 
CHewitt-Smith75, Hewitt77) 
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components of a data structure. For example, a node in lst structures of LISP has two : 


conceptually different kinds of ia Sona a aad tay oe The following 


(NODE (ear: 10) (edr: 12)) | - 
“expresses a node whose car-part and cdr-part are 10 and 12, respectively. (cer: 10) and 
(edr: 12) are c-packages. Selectors of packages (eg. cer and ee in the 


"tower case italic letters followed by a colon. 


When the details or specification of some components of a data structure are 
be placed in conceptual representations. For example, when we want to express a node’ 
whose car-part is IS, but cdr-part may be anything, 

(NODE. (cer: 13) ledr: 2)) 


may be used. We call the question marks used tr'this way dusky dement notistions. 


2.2.2 C-sequences 


There are many data structures which are naturally viewed as a linear sequence of 
components at some levels of abstraction. Queues, stacks, arrays, tables and etc. are 
examples of such data structures. To express. such conceptual sequences of components in 
data structures, we use a syntactic construct, conceptual sequences (abbreviated as 


c-sequences). i 


1. Specifications of forms in ALPHARD[Wulf-et-al?6) are stated in terms of mathematical 
i a a aa 
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Let us consider queues to sée how c-sequences are used. Programmers envisage a 
queue as a linear sequence of elements which sre enquaued at one end and dequeued: from 
the other end. Suppose that we have a queue consisting of three elements, I, 2, and 8, where 
1 is its front element and 5 is its rear element. seen eer © ae ee ee is 
expressed by the following conceptual representation. 


(QUEUE {1 2 3)) 
When a new-element 4 is enqueued at the rear end of this queue, this queue is expressed as: 


(QUEUE [1 23 4). 


2.2.3 Unpack Operations and Dot Notions 
In order to express a queue which has an indefinite number (including zero) of 
elements, we use a c-sequence variable, say x, in conceptual representations as follows: 
~ (QUEUE [t)) 


§x is an abbreviation of the “unpack” operation on x... 

___ In general, expression is equivalent to .welting out all.of the elements of the 
c-sequence denoted by <expression> individually, . Faresample, auppnee that x denotes a 
c-sequence [2 3 4]. Then 


[1 x] = [1 123 4}) = (123 4) 
whereas 
{1 x] = 1 [23 4) # (123 4) 


When y denotes an empty c-sequence {], 
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(1 by) = [1 8) = [1} 

Thus. (QUEUE [8y)) is equivalent to (QUBUE []): which is the conceptual representation of 
an empty queue. 

ka able hana cae Gh cancapesh pamaamatio OE gacees 
which use unpack operations and c-sequence variables. The twe conceptual representations: 

(QUEUE [6 i2}) = and = QUEUE [& 9) 

express a queue whose front Seen 3S ees ty ee eee oan ee ee 
last element is 9, respectively. Furthermore 


(QUEUE [i 8 fy) 

expresses a queue which has 8 as one of its elements. When the elements before and after 
8 (Le. §x and By) in the queue are uninteresting, the folowing concen representation may 
be used. 

(QUEUE [.. 8 ..}) 
“." inside the c-sequence is called a dot notation. In general, dot notations are used to 
indicate only the existence of an indefinite number: (including zero) of elements whose 
Specification is not important ina c-sequerice or c-colfection. (Cf. 22.4) Dummy element 
notations may be used as-elements of c-sequences. For example, a conceptual representation: 

(QUEUE [3 48) | | 


describes a queue whose front element is unknown ( or unimportant), and the rest of whose 
elements are 3, 4 and 5, in this order. 


2.2.4 C-collections 


Another syntactic construct of conceptual representations is conceptual collecttons 
(abbreviated as c-collections) which are used to represent a conceptual group of components 
in data structures. C-collections are different from _ sequences in that the order of 
elements in c-collections is unimportant. For example, a ‘collection ir 3 7} is equivalent to 
both {2 7 3} and {7 3 2}. C-collections are also different from mathematical sets in that 
muttiple occurrences of the same elements in c-collections, are important. For example, a 
c-collection {2 2 7} is not equivalent to {2 7}. 

A simple example of conceptual representations using c-collections is 


(SET {3 4°5}) 


which expresses a data structure of the type “set” whose elements are 3, 4, and 5. An 
indefinite number of elements of a c-collections can be ‘expressed by the unpack operations 
and c-collection variables. Thus a general form of the conceptual representation for the 


data structure “set” may be expressed as 
(SET {8x}). 


C-collections may be described by using dummy element netations “7” and dot notations *..” 


' in the same way as c-sequences. 


2.2.5 Pattern Matching 


Unpack operations are extremely useful in pattern matching! of c-sequences and 
c-collections. Below we will give basic examples ol pattern matching, instead of presenting 
the matching algorithm. 


‘Suppose that a c-sequence of four r numbers tt 9 8 4 matches againa the 1 following 


| @) (1 te), u inust be [9 8 4}. 


(2) (iv 8 4], v mast be [1 9]. 
(3) [tw,  - wemue bv E98 


(4) [Su 8 fv}, uand v must be (3 9] end.. [4], respeceively. 
(5) ees psn. 


Suppose that the same c-sequence matches against, the e folhawing patterns, where M and N 
are pattern (or free) variables on numbers. 


(6) [M tu}, M and u must be 1 and [9 8 4), respectively. 
(7) (fu N), uand N must be:[1.9 Sh and 4, respectively. 


But [1 9 8 4] does not match against the following pattern: 


(8) (MN). 


Some patterns may have more than one matching case. For example, when [1 9 8 4) 


‘ matches against 


i. The use of pattern matching in our specification and verification techniques will be 
exemplified in the process of symbolic evaluation in Chapter 5. 
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(9) [1 8uM Sv], there are three matching cases: 
Case-!: u=([j, M=9, v=([8 4]. 
Case-2: u={[9], M=8, v= [4]. 
Case-3: u=[9 8], M=4, ve[]. 
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Fig. 2.1. Syntax of Conceptual Representations in BNF 


<conceptual-representation> = ( <keyword> ) 7 ( ckeyward> <cramneptsaheonstituents> ) 
Lin tiininawenidikeat:° °° | * 
<conceptual-constituents> ::= <an-entity> | <c-sequence> | <c-collection> | <c-package-sequence> 
<an-entity> <= % a single conceptual entity, which is often en ecter % | 
<c-sequence> z= [ <juxtaposition> ] | 

<c-collection> ::= { <juxtaposition> } 

<c-package-sequence> = <c-package> | <c-package> <c-package-sequence> 

<c-package> «= ( <selector> <conceptual-constituents> ) 

<juxtaposition> := <element> | <element> <juxtaposition> 

<selector>.: = tam identifier in she lower case lle font followed by « colon z 


<element> ::= <empty> | <an-entity> | <c-sequence> | <c-collection> I 
<c-package> | <unpacked-c-sequence> | <dot-notation> | <dummy-element-notation> 


<empty> := % an nny ne r 4 

<unpacked-c-sequence> == areas | f<c-sequence-variable> 
<dot-notation> := ... 

<dummy-element-notation> <= 7 


<c-sequence-variable> := % an identifier in the lower case roman fom 7% 
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2.3 Specifications of Data Structures 


In this section, we exemplify how conceptual representations are used in 
specifications of data structures. An abstract data type [Liskov-Zilles74] or a data structure 
is specified by the functionality (domains and ranges) of the applicable operations and the 
effects of these operations. If the data structure may be created by users, how it is created 
must be also specified. In specifying functionalities, a notation “error” is used to denote a 
set of error messages which warn users of operations that an error has occurred. We 


assume that data structures are not changed by operations which cause error messages. 


2.3.1 Queues 


As suggested in the previous section, we use conceptual representations of the 


following form to express a queue. 


(QUEUE [..}) 


A complete specification of queues is given in Figure 2.2. 


Fig. 2.2. A Specification of Qpewes 
FUNCTIONALITY: 
i) CREATE-QUEUR:  =-~>. queme . 
creates an. empty queue. 


"—_enqueues anew item at the rear end of the queue. 
Wi) DEQUEUE: queue —> item x queue or error 
iif the queue is empty, an error menage is produced. 


tv) IS-EMPTY: queue -—> boolean 


EFFECTS: a Rote 
(1) CREATE-QUEUE() ----> (QUEUE [) 


(2) cunsataie [ix}), A) ----> (QUBUE [ix AD 
(3) DEQUEUE((QUEUE [)) --—-> ERROR 

(4) DEQUEUE((QUEUE [A Ix})) ----> <A, QUEUE (hb 
(5) IS-EMPTY((QUBUE [)) ----> rt 


(6) IS“EMPTY(QQUEUE [A tx) --—-> FALSE 


2.3.2 Sets 


A ra use of conceptual collections in conceptual poeenan is the data type 
“set”. The following four operations are associated: witis:the set type. 


FUNCTIONALITY: ° 
1) CREATE-SET: ===> set 
screates an empty set. 


li) INSERT: element x set ===> set 


stries to insert an element, 
3if the element is already in the set, no effect. 


Wi) DELETE: element x set ---> set or error 


itries to delete an element from a set. 
if the element is not in the set, error. 


iv) INT: element x set ---> boolean 
_ checks whether or not an element is a member of a set. 


The effects of these operations are formally described in Figure 23. Note that the 
membership of an element in a set is expressed succinctly by dot notations in c-collections. 


Fig. 2.3. A Specification of Sets 


EFFECTS: — 7 
(1) CREATE-SET(). ~---> (SBT f}). - 


(2) INSERTEE, (SET {8x})) 


if xe{.£.} <-> (SET {hx)- 
if xe {.E} => (SET {fx E}). 


(3) DELETECE, (SET {$x})) wes. © 
ifx={iyE be} <--> (SET {ly }) | 
ifxv{E.} > ERROR 


(4) INTCE, (SET {8})) 


if xe{E.} 9 > TRUE 
ifxe{E.} > FALSE 


2.3.3 Arrays 
The following five operations are associated with the array type. 


FUNCTIONALITY: 
1) CREATE-ARRAY: integer x integer —> arrey or error 
itries to create an empty array with the specified lower and upper bounds. 
ithe first integer should not be greater than the second integer... 


ii) STORE: array x integer x item ——> array or erro 
-. jtries to store an item with the specified iridex 
“athe index should be within the bounds. “3 


iil) FETCH: array x integer —> item or grror 


dries to fetch an item with the specified index 
the index should be within the boulids. 


lv) BOTTOM: array ---> integer 
wreturns the lower bound. 


v) TOP: array --> integer 
returns the upper bound. 


To express arrays, we use conceptual representations of the following form: 
(ARRAY (lose: |) (hégh: h) (elements: {...[) A]..})) 


where | and h are the lower and upper bounds, respectively, and an item A with the index i 
is expressed as a c-sequence [i A] in the c-collection of the (elements: ) cpackage. The 
effects of the operations applicable to an array is given in Figure 2.4. 

Multi-dimensional arrays can be expressed easily by modifying c-sequences in 


Fig. 2.4. A Specification of Arrays 


EFFECTS: 


(1) CREATE-ARRAY(, h) 
Uf 1S, ==> (ARRAY (oa: 1) Unigh: h) (elements: {})) 
if toh mm? BROOK hound rver, 


(2) STORE((ARRAY (low: 1) (igh: h) (elements: {i})), i A) 
if i> hor i<l, ---> ERROR . ge es sbound error. 
if 1SiSh and x= (toi {i 7%}$e2} . _:: + -guban the tele cloment elready existe. 
| —> (ARRAY Wows 1) Uhathe bi Aolamente: {$e {+A} t02})) 
if \Sigh and x#{..fit].} shen the i-th element dees net exist. 
sds CARRY ic 1) et iomane ef ADD 


Sty 


(3) FETCH((ARRAY (ow: 1) (high: W llamene: fei. . 
if i> hor i<t, <--> ERROR | sbound orrer. 
if 1S$iSh and xe{.[iB].} -——> B ee es 
Uf WSiSh and x#{.[iT].} <-> ERROR  jehon the i-th element is not found. 


(4) BOTTOM((ARRAY (low: 1) (high: h) (elements: {..}))) <--> I 


(5) TOP(ARRAY (lose: |) (high: h) (elements: {}))) ---> ho 
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the (élements: ) c-package to include more than one index. For example, a two-dimensional 
array may be expressed by a ‘conceptual representation of the following form 


(ARRAY (low: 1) (high: b) (olomonner {014 A} = 10 


2.3.4 Symbol Tables 


As an example of specifications for more complicated data: structures, we give a 
specif ication of symbol tables [Guttag?5, London-et-al76). Symbol. tables. are often used in 
writing compilers for programming languages which have ALGOL-tike block structures. A 
symbol table records pairs of an identifier and its ateribute. ‘The same identifier may have 
different attributes depending upon where the identifier ts used: f'tHte Block structure. We 


assume the following six operations are applicable to,8 symbol table. No operations except 
ENTER-BLOCK are allowed before the most global block is entered. The creation of a symbol 


table does not Imply the emering ofthe mos global bik. 
FUNCTIONALITY: 


i) CREATE-SYMBOL-TABLE:  -~-~>_syunhel-table 
icreates an empty symbol table.. 
ino block has been entered yet. 
li) ENTER-BLOCK: symbol-table ----> symbel-table = 
sset up a new local naming scope. 
ii) LEAVE-BLOCK: symnbol-table ----)  puibal tall or error 
jtries to leave the current block. 
iif the current block is outside the most global one, then error. 
jotherwise discard the current block and reactivate the most previous scope. 


oy 
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tv) ADO: s table x id x attribute ----> symbol-table or error 
itries to add a pair of an identifier and its attribute. 
iif the current scope is outside the most global block, then error. 
iif the identifier is already declared in the current ‘block, then error. 


v) RETRIEVE: symbol-table x id ----> attribute or error 
tries to retrieve the attribute of an identifier in the most recent 
block in which the identifier is declared. 
if it ts not.found, then error. 


‘As a conceptual representation forthe symbol bl, we use the ftlowing notation: 
(sy MBOL-TABLE [tp 
x is a c-sequence whose name empty or c-packages of the form 
| (lock: yD 


which conceptually represents a block. The order of cpackages in x crepes to the 
order of blocks. That is, the last c-package in x « corresponds to the most recently entered 
block. y is a c-sequence whose elements are pairs of an identifier and its attribute. Such 
pairs are expressed by a c-sequence. Fer example, suppose that fn sore block identifiers A 
and B are declared to be real and integer, as ai Then ( comceeae representation 
for this symbol table looks like: 


(SY MBOL-TABLE [ ..0bteck: [... [A real) ~ (8 integer) =) -D. 


Using conceptual representations of this Form, a specication of ‘symbol | tables is written as 
depicted in Figure 25. 
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Fig. 2.5. A Specification of Symbol Tables 
EFFECTS: — 


(1) CREATE-SYMBOL-TABLE() ---> (SYMBOL-TABLE [)) 
(2) ENTER-BLOCK((SY MBOL-TABLE [fu})). ---> (SYMBOL-TABLE [2u (block: [))) 


(3) LEAVE-BLOCK((SY MBOL-TABLE [) ---> ERROR 
— Jeaving the most global block (without entering). 


(4) LEAVE-BLOCK((SY MBOL-TABLE [tw (block: [..}}})} ) ---> (SYMBOL-TABLE [fw)) 


(5) ADD((SYMBOL-TABLE [}), ID, ATT) ---> ERROR | 
adding an id-attribute pair shessent most etobal block: 


(6) ADD((SY MBOL-TABLE {ir Glock: [tpeirepD, 10, am 
if peiree(.(ID?]..)  ---—> ERROR {1D is already dectared in the current block. 
if pairs #[.. {10 2] _ J 
-—-> (SY MBOL-TABLE (tr (block: Utpeire nm ATTInD 
(7) RETRIEVE((SY MBOL-TABLE [It)), 1D) 
if t # [..<block: [.{1D ?}..})..) <--> ERROR 
ithe identifier is not found in any blocks. 


if t = [...(block: [..[I0 ATT] Ex}) fy) and y # [.Gbleck:[-{1D T].))..] ---> ATT 


2.4 Relationship to Other Work 


In this section, we discuss the relationship of our specification techniques for data - 
structures presented in this chapter! tw some other: work: in the sashe eaten. “We have chosen 
to consider an algebraic axiomatic approach and an abstract model approach because these 
two approaches are in clear contrast to ours and alko' well sitidied. ‘An exceflent survey of 
specification techniques for abstract data types is found in OLishov-Ziltes75). Other 
approaches such as Parnas’s “wate machine model” TParnas72), are ‘abso reviewed in 
ULiskov-Zitles76] 


‘2.4.1 rae Axiomatic Approach | : 


Algebraic. axtomatic schnlgese: Nano: Mata: steadied by a number of researchers 
[Zilles74, Spitzen-Wegbreit75, Guttag75, Wegbreit-Spitzen?6)._ In this approach, the effects 
of operations on an object of the data type being speified are exprescd in terms of 
equations ‘of ‘the operations. To compare their “approach with ours, we present two 
algebraic axiomatic specifications, ane for queues. (whichis: &: modified version of 
{Spitzen-Wegbreit75]) in Figure 26 and the other for biponen tables sare a _ Slightly 
simplified version of [Guttag?5)) in Figure 27. j 

All the axioms given in their specifications in Figure 28 and Figure 27 are easily 
derived from our specifications of queues in "Figure 22 and symbol tables in Figure 25. 
[For the derivation of the axiom (5) in’ Figure 26,"see ‘Appendix 1)’ We believe that 
Specifications using conceptual representations are often easier for programmers to both 


1. In this chapter, we assume that data structures or data types are always used in serial 
computations. Our techniques for data structures (or abstract data types) with parallelism 
and side-effects will be presented in the later chapters. 
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Fig. 2.6. An Algebraic Axiomatic Specification of Quewes 
FUNCTIONALITY: omitted. | 


AXIOMS: | 
(1) TS-EMPTY(CREATE-QUEUE()) = TRUE 


(2) 1S-EMPTY(ENQUEUE(Q, A)) = FALSE 
(3) DEQUEUE(CREATE-QUEUE()) = ERROR —_—_ attempts te dequeue on empty queue. 
(4) if IS-EMPTY(Q) then “DEQUEUECENQUEUE(Q, A)) = <A, > 


(5) if =IS-EMPTY(Q) A DEQUEUE(Q) = <8, Q> 
then DEQUEUE(ENQUEUE(Q, A)) = <8, ENQUEUE(Q’, A)> 


construct and understand than algebraic axiomatic specifications, because in the conceptual 
representation approach we describe directly and explicitis what effects take place in data 
structures (at the conceptual level) when the operations are applied, whereas the algebraic 
axiomatic specif ications describe the effects of the. operations indirectly and implicitly in 
terms of retations (or equations) among the operations. In particular, the axiom (6) for 
symbol tables in Figure 2.7 is expressed in terms of- a recursion of RETRIEVE. Such indirect 
specifications are often difficult to grasp. Thus the author and reader. of an algebraic | 
axiomatic specification of a data type may be less. confident as to whether or not the 
specification completely describes the desired. properties of the data type. 

Recently a serious problem in the algebraic approach has been pointed 
out(Majster77] The problem is that there are some. classes. of abstract data types which 
cannot be specified by a finite set of axioms for the operations (equations of the 


Fig. 2.7. An Algebraic Axiomatic Specification of Symbol Tables 


FUNCTIONALITY: omitted. 
AXIOMS: 


(1) LEAVE-BLOCK(CREATE-SYMBOL-TABLE() = ERROR 


(2) LEAVE-BLOCK(ENTER-BLOCK (symteb)) = eymteb 
(3) LEAVE-BLOCK(ADD{eymteb, id, attre)) = LEAVE-BLOCK{aynioh) 


(4) RETRIEVE(CREATE-SYMBOL-TABLEQ, id). ERROR 
(5) RETRIEVE(ENTER-BLOCK (eymiab), id) aerate id) 


(6) RETRIEVE(ADD(eymtab, td, attrs), idi) 


¥f id = idl, . 
then attrs 
else RETRIEVEtsymteb, it) 


operations). To avoid this problem, they must use axiom schemata instead of infinitely 
many axioms. This violates the finiteness of the axiom set Which is an important 
assumption of the undertying theory fot algebraic speciftcitieh techniques. Our conceptual 
" representation approach does not have suct a problem, becative, as. mentioned above, our : 
techniques destribe explicitty what effetts the Operations cause to data structures. (In 
appendix II, a data type which cannot be expressed by a finite set of sigebrate axioms of 


operations is specified by using conceptuat representations) — 
Furthermore, the- current algebraic and sxtomatic 
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important difference between data structures without side-effects and data structures with 
‘side-effects. (This difference will be explained in Chapter 8).....As will -be seen in Chapter 
4, the specification technique using conceptual representations can easily express this 
difference. For further discussions on the algebraic approach, see Section 433, Chapter 4. 


2.4.2 Abstract Model Approach 


B. Liskov and V. Berzins (Liskov-Berzins77], have been developing ‘an abstract 
model approach in the area of specification of abstract data types. The construction of its 
mathematical foundation is underway (Berzins?6]) Int this approach, first a certain set of 
well established data types and mathematical objects [eg., sets, sequences, tuples and etc.) is 
chosen. Then new abstract data types are © specitiad in terms of such chosen data types or 
already defined abstract data types. 

As an example, we give an abstract model specification of arrays cited from 
(Liskov-Berzins77] in Figure 2.8. Objects of the type errayft] are represented by the 
following tuple: | | 


tupleflow: integer, 
high: integer, 
elements: ‘sequenceltuptefinder: integer, value: ui 
Comparing the specification in Figure 28 with the one given in Figure 2.4 which is based. 
on the conceptual representations, one is struck by the similarity. In fact, in representing 
objects of -a new data type, the roles of sequence, sets and tuples in their approach 
correspond to those of c-sequences, c-collections and c-packages in our approach. However, | 


in the abstract model approach, the operations applicable to objects of a new data type are 
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Fig. 2.8. An Abstract Model Specification of Arrays 


FUNCTIONALITY: 


OPERATIONS: 


altoc(il, 12) = 


_ bottom(a) = 
top(a) = 


store(x, i, a) = 


fetch(i, a)= 


getvaKelements, i) = 


if il s 12 then flow: il, high: 12, elements: <>} 
else error(bad array size”) 
s> denotes an empty saquence and {..} denotes a tuple. 


a.low 
a.high 


ifatowsisahigh | 
then { low: a.low 
high: ahigh 
elements: addfirst({index: i, value: x}, a.elements) } 


if alow sis a.high then getvalla.clements, i) 
else error(“index out of bounds”) 


if length(elements) > 0 then 
if elements,.index = then elements;.value 
else getvaXbutfireslelements), i) 
else UNDEFINED 
elements, means the first item ef the sequence densted by “elements: 
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specificed in terms of procedures defined on pre-defined data types. Getval, addfirst, and 
butfirst in Figure 2.8 are examples of such procedures. In the conceptual representation 
approach, we do not use such procedures in specifying the effects of the operations. 
Instead, we rely on pattern mechanisms of keywords, c-sequences, Ccotjectiont and 
c-packages, which have been exemplified by a number of specifications. | 

As was pointed out in the previous subsection, our approach is extended easily to 
cover data structures with side-effects. The extendability of the abstract mode! approach 


remains to be seen. 
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3. Behaviors of Actors (A Model of Computation) 


In this chapter, we introduce the model of deterministic computation on which the 
discussion in the rest of this thesis is based. The first section mainly contains definitions 
and intuitive accounts of various concepts and notations employed in the model of 
‘computation. The second section describes the characteristics which must be considered in . 
trying to construct formal specifications of computations in the model. This section 


contains the classification of interactions among actors. 
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3.1 The Actor Model of Computation 


The fundamental objects in our. model of computation are: actors. Computations 
are carried out through message passing between actors. -Anm actor is:a potentially active 
- object (procedure) which becomes active when it receives a message. Each actor decides 
itself how to respond to messages sent to it. No actor can treat other actors as objects to 
operate o on: it can only send a message to other actors! . 

Messages are also actors. An actor may be created in the course of ‘computation or may 
exist in the beginning of a computation. More than one transmission of a message at a 
time in an actor system may take place. . 

A collection of actors which communicate and cooperate with each other in a goal 
oriented fashion can be implemented asa single actor. A system of actors can model 
various kinds of information processing schemata from ordinary sequential arithmetic or 
symbolic computations to highly distributed parallel computations including computer 
networks of varying scales. Furthermore, it can model problem solving activities by a 
moctety: of experts{Hewitt77]. | — 

A number of concepts in programming systems can be captured by simple concepts 
in the actor model of computation. For example, traditionally different kinds of entities 
such as data, data structures, files, and procedures are unified as a single kind of ob ject, the 
actor. Control structures such as recursion, iteration, and coroutines can be viewed as 
particular patterns of message pasting {Hewitt77] Furthermore, calling a procedure, 
returning a value, retrieving and updating data structures, and synchronization and 
communication of cooperative parallel processes are achieved by message passing. 


1. For example, to get the i-th element of an array A, an (i-th:) message is sent to A instead 
of doing a fetch operation Ali). 
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An implementation of the actor model of. computation has been realized as a 
programming language PLASMAIHewitt-Smith?5, Hewitt771 The syntax of PLASMA is 
so designed that its underlying semantics is transparent:: 

_ The above haa aa ae more 
precise below. 


$.1.1 Actors 


An actor consists of two parts ‘script (action) and acquaintances Its script is a 
| description of how it should respond to messages sent to it. Each actor has a fixed set of 
messages by which it can be activated. When a message that does not belong to this set is 
sent to an actor, the response of the actor is undefined. The acquaintances of an actor are 
a finite collection of actors that it directly hnows about An actor A can send. a message 
directly to an actor B only when B belongs to the Aequaintances: of A. The script. of an 
actor can be realized bya a PLASMA program for the actor. The acquaintances of a newly 
created actor C are the set of actors which are denoted by free identifiers in the PLASMA 


program for C at the time of creation. 


3.1.2 Events 


An event E is defined to be the receipt of a message! actor M by a farget actor T.- 
The event E is expressed by a notation of the form 


I. We use the terms “receipt” and “arrival” of a message poten throughout the 
thesis. on 
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[ T <== M J. 


A message contains a request of what the target actor is asked to do and it may also 
contains a continuation actor which is the destination where the reply to the request is 


supposed to be sent. Messages are often expressed by notations of the form 
[request: <request> reply-to: <continuation>). 


The request usually consists of a tag which indicates a task to do and the data necessary to 
accomplish the task. PLASMA packages are often used as requests. For example, to request 
a queue-actor to enqueue some actor A at the end of the queue, the package (enqueue: A) is 
used. To request a queue-actor to send back its front element, the package (dequeue:) is 
used. The continuation actor may be omitted in the message when it is unnecessary. For 
‘example, when the oe of a message is to return the result of a task, or the reply toa 
request, the message need not contain a <continuation>. In such cases, messages are expressed 


by notations of the form 
[reply: <result>] 


When a continuation C in a message is unimportant or obvious from the context of 
discussion, we make only the request part explicit in expressing an event. So the following 


abbreviated form is used 


[T <= <request)] for [[T <== (request: <request> reply-to: C]]. 


Furthermore, when it is obvious from the context that a message contains only a replying 


result, we use the following abbreviated form. 
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[TT < cresui] for [T coz freply: <result> J. 


Note that the above abbreviated forms use. single shafted arrows "<=" instead of double 
shafted arrows “<an”, In the subsequent presentation of this thesis, the terms “request” and. . 
“message” will be used interchangeably when we are.not interested in the continuation in a. 
message. aid | 

A primitive event is an event which activates exactly one immediate reply without 
causing any antermediate events. From this Gefinikion, we can. Gefine t primitive actors. A. 
Primnltoe actor is an actor which always causes a primitive event when it is sent a message. _ 

As we have noted above, different control structures in programming languages 
are viewed as different patterns of message passing in the actor model of computation. In_ 
fact, such different patterns of message passing correspond to different patterns of 
‘continuation in messages. The patterns of continuation for recursion, and iteration are 
found in [Hewitt77] and for coroutines in [Greif-Hewitt?5). The fact that continuations are 
sent together with requests allows the unification of contro! flow and data flow into a 
universal flow of information, message transmission. Consequently, this unification allows | 
us to describe computations solely in terms of events.. | 


3.1.3 Computations 


A computation is defined as a partially ordered set of events, where the ordering is © 
Strict and transitive.- A physical intuition. for the orderimg i<that an event E precedes 
another event E’. We call this ordering the precedes order and denote it by “-->". Then a 
computation is a pair <Ev, "-->"> where Ev is a set of events. The strictness of the a 


imposes the constraint that any event E does not precedes itself: 
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V E, “(E --> E). 
The partialness of the ordering allows that some events Ej and E j do not precede each 
other, which means that Ej and E j my take place concurrently. We assume that each such 
ordered set of events always has the maximal events in it. This means that every 
computation has a set of initial events. 

Our assumption to model physically realizable computations requires two kinds of 
finiteness properties. First, for any two events E; and E j which are ordered by "-->", only 
finite numbers of event can take place between E, and E j Le., the set {E|E; -> E--> E ; is . 
finite. Second, each event E has finitely many immediate successor events. These two 
finite properties do not rule out non-terminating computations: they only exclude infinitely 
fast computations.! 

The precedes ordering has two suborderings which reflect more detailed physical 
properties of computations. Suppose that E is an event in which a target actor T receives a 
message actor M. Then the event E triggers a response (or action). This response is a 
finite set C of events. We can view that the event E activates the events in C. Thus we 
call this type of ordering the activation ordering and denote it by “-act->". So V EE in C, 

E -act-> EE. The activation ordering is intended to describe the notion of causality in 
computations. 

Suppose that more than one message is sent to a single actor A in a computation. 
In our computation model we assume that one message arrives before another. I.e., no two 


messages arrive at the same actor simultaneously. Since each arrival of a message at A is 


an event by definition, if we fix a target actor, we can always introduce an ordering among 


i. Hewitt and Baker gave an proof for the impossibility of such infinitely fast 
computations in (Hewitt-Baker77]. 
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events which have A as a target actor by arrival tise. We call this ordering the arrival 
ordering with-respect to. A and denote it-by “-err->,". | 

The important property of the arrival ordering is that it -is:a total order: each 
event in a@ computation.can have at most one immediate successor event in terms of the 
arrival ordering, whereas it may have more than one immediate successor event in terms of 
the activation ordering. , | 

_ A nested activity is a computation satting witha are event RQ of the form 


Se eer 
and ending with the corresponding réply event RP | 
LL <cpatinustiony cns reply: Ghecroua 
The set of events consisting of the nested sin the am 
{E1E=RQvE=RP v(RP ere 


When a continuation is not contained in the message, the nested activity is undefined. 
There are many activities in operating systems and distributed computing systems 

that are not nested. It should be pointed out that. one, may, 1 find many non-nested activities 

in the real warld. The model of a post office given in Chapter & is an example of such 


non-nested activities. 
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3.1.4 Level of Detail 


The behavior of an actor system can be described at varying levels of detail. 
Computing the factorial of 3 can be viewed as a process to input 8 and to output 6 at some 
level of detail. At this level of detail, an iterative way and a recursive way of computing 
the factorial of 3 are viewed as the same computation. Some difference between . two: 
implementations of the iterative factorial may be detected at some finer level of details. 
There may be many implementations of an actor ‘whicW satisfy’ giver ‘specification. Such 
implementations are viewed as the same. implementation at ore’ level and ‘different ones at 
another level. At a finer level, some computations which may be viewed as a serial 
computation at a less fine level may be revealed to be parallel computations. | 

In order to describe the behavior of an actor system ¥ we need to choose a level of 
detail accousine to the purpose of description. The description of the behavior of an actor 
system at the lowest level of detail is given asa \ computation <Evo, ” = > where Evg is a set 
of all events which take place in the actor system, A level of detail is decided by criteria 
with which a subset Ev is chosen fr rom Evg Since anye events Ea and E yin Ev are also in 
Evo, if E, and E, j are ordered by "-->" in Evo. the same order relation holds in Ev. Thus a 
partially ordered set of events Ev is a “sub"-computation of Evo. Choosing a subset from 
Evo is done with various criteria which are decided by the purpose of description. For 
example, first we select actors from the set of ail actors in the system, and then all events 
where the selected actors are involved as targets or messages are chosen from Evo. Another. 
‘example of the criteria is to select events which meet some patterns such as the beginning 
and ending events of nested activities. 

The notion of primitiveness defined in the previ subsection is ‘Telative to the 
level of detail chosen. The event ‘where ‘the factorial actor receives $ is primitive at. the 


level of detail where no events taking place. before the arrival of 6 at the continuation are 
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counted. An event where a data base receives a query can be viewed a3 a primitive event 


at a very high level of detail. Thus a Gata base | an be -cedesgaarsha asa primitive . actor at 
that level. 


3.2 Time Variant Heheviers of neers : 


In this ‘gection. we. discuss the characteristics-of iadividual-actors which must be - 
taken into account in formally specifying the behavior of an:actor system. 


3.2.1 Pure Actors and Impure Actors 


All actors are classified into two categories depending upon their behavior. Actors 
which belong to one category never change their behavior. They always give the same 
reply to the same request. They 2 are called pure actors. Actors which belong. to the other 
category are called impure actors and their behavior may change with time. They do not 
always give the same reply to the same request. The e folowing n more e precise definitions are 
given in terms of nested activities! 


An actor T is pure if, for the same message M, the « event UT <= M] 
always causes s (precedes) the same 0 reply event. 


l. The definitions can be viewed as behavioral definitions of immutable. and mutable 
ob jects. 
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An actor T is impure (not pure) if there is a message M such that the event 


[T <== MJ] does not always cause (precede) the same reply event. 


The “sameness” in the above definitions is used in the following sense: two actors are the 
“same” if they are behaviorly equivalent! Two events are the same if they have the same 
target actor and the same message actor. | 

From this definition, it can be said that a pure actor behaves like a mathematical 
function. An actor which generates random numbers is impure because it returns a random 
number in response to the same message (next-random-number:). A cell-actor is another 
example of a simple impure actor. A cell-actor accepts a message (update: <new-content>) 
which updates its contents and a message (contents:) which retrieves its contents. A 
cell-actor may change its behavior because it can give different answers to the (contents?) 
message, depending upon what it contains at the moment. An actor which behaves like a 
function + is a pure actor. The plus-actor always returns the same number, which is the 
sum of two numbers sent to it. Another example of a pure actor is a sequence-actor. One 
can retrieve elements of a sequence-actor, but one cannot change its elements; instead a 


. completely new sequence-actor must be created. So a sequence-actor is pure. 


3.2.2 Pure Queues and Impure Queues 


To illustrate the difference between pure actors and impure actors, let us consider a 

pure actor and an impure actor, both of which behave like a queue. Both pure 
queue-actors and impure queue-actors accept the same two kinds of messages: one is (nq: x) 
1. For example, number actors which behave like 1 are behaviorly equivalent each other, 


but their identity may be distinct. The LISP functions, EQ and EQUAL, are impure and 
pure, respectively. 
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which is a request to enqueue a new elements x, and the other is (dq:) which is a request to 
take out the front element of the queue and return it with the remaining queue. However 
if the queue is empty, it returns a complaint message (exhausted:). The important | 
difference between a pure queue-actor and an impure queue-actor is whether or not a new 
queue-actor is created when (nq: ...) and (dq:) are sent. When (nq: x) is sent to a pure 
queue-actor PQ, a new pure queue-actor PQ’ which has x as the last element of the queue is 
created and returned. The original queue-actor PQ still has the same elements as before. 
When (nq: x) is sent to an impure queue-actor IQ, x is absorbed inside IQ and enqueued at 
rear of the previous elements. So IQ itself is extended and returned. No new queue-actors 
are created. (See Figure 3.1.) 

When (dq:) is sent to a pure queue-actor PQ (which is not empty), a new pure 
queue-actor PQ’ whose elements are all elements of PQ except the front element of PQ is 
created and the front element of PQ and the new pure queue-actor PQ’ are returned. 
Again the original PQ is intact and has the same elements as before. When (dq:) is sent to 
1Q (which is not empty), then the front element of IQ and IQ itself which now has the rest 
of the original elements are returned. No queue-actors are created. 

It might be helpful to see a LISP analogy in understanding this difference 
between pure queues and impure queues. Suppose that a queue is implemented as a list L. 
Then sending (nq: x) to a pure queue-actor corresponds to (append L (list x)), whose result is 
a totally new list constructed from a copy of L and x. Sending (nq: x) to an impure 


queue-actor corresponds to (nconc L (list x)) whose result does not consist of a copy of L. 
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Fig. 3.1. Behaviors of pure queues and impure queues 


- 54- 
3.2.3 Sources of Impurity and Uses of Impurity 


The change of behavior of an actor A is caused by the change of information 
used in computing the reply for a request to A. The change of such information is caused 
by the computation taking place before the reply event occurs. 

Roughly speaking, the sources which may change the behavior of an actor A can 
be divided into two kinds. One is the activation of A initiated by messages which have 
been sent to A. The previous activations of A change the information stored inside A. For 
example, a random number generator usually keeps some internal values used to generate a 
random number. For the generation of the next random number, such internal values are 
changed during the generation of the previous random number. In the case of impure 
queue-actors, the history of the previous enqueuing and dequeuing operations determines 
the reply for the current dequeuing request. 

The other kind of source is the computation initiated by messages which are not 
sent to A, but to some other actor B. When the computation initiated by a message sent to 
B changes information shared by both A and B, the subsequent behavior of A may change. 
Sharing of information sometimes happens inadvertently. When an actor A is created, 
some internal constituents of A might become known to other actors outside. For example, 
Suppose that a new array-actor A is created by extending the upper bound of an existing 
array-actor B. If B receives a request to change one of its elements, the computation 
initiated by the request will change the subsequent behavior of A, because all elements of B 
are shared by A. There is another way in which internal constituents of an actor A become | 
accessible. After an activation of A, the some internal constituents might be released 
- outside as a result of the activation. Such released constituents become directly accessible 
from outside and information stored in them could be changed without sending legitimate 


requests to A. 
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Uses of an impure queue-actor are “destructive” in the sense that each enqueuing 
or dequeuing messages sent the actor changes the current status of the queue. If one wants 
to update the queue and still keep the previous status of the queue, the behavior of pure 
queue-actors is desirable even if it is costly in terms of both space and time. Sometimes the 
impurity of actors are necessary. For example, in order for coneurrently running processes 
to communicate with each other, they need some actor which behaves as information 
storage through which they may exchange information. Such information storage may be 
contained inside each process or external common storage to which concurrent processes 
have access. This kind of impurity of actors is indispensable for communicating parallel 


processes. 


3.2.4 Four Types of Interactions ones Actors 


Suppose that an actor M is sent as the request part of a message to a target actor 
T. This event initiates a computation where M and T are involved [ie. an interaction 
between M and T]. After this computation, there will be no changes in the behavior of M 
or T if both M and T are pure actors. If M or T, however, are impure actors, the 
‘subsequent behavior of M or.T may be different. -Interactions between two actors M and 
T are classified into four types, depending apa me presence or absence of change in their 


future behavinn: 


No-Change-Type: Neither M nor T change their behavior. 
The interactions initiated by the following events: | 


[factorial <x 3] 
[create-array <= 4] 
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[merge <= [ARRAY-1 ARRAY-2]] 


are examples of this type. The objective of this type of interaction is creation of 
new actors. Neither the tecterial actor-nor. the number-actor 3 change their 
_ behavior, but the resuk of the computation; a  mamber-actor ‘6, is created and = 
returned. The crestererray. actor alwaysicreates an arry-of the size specified by the 
request message. _ ‘The merge actor creates. a new sorted afrays whose evéments are 
those of the two sorted arrays. ARRAY*1 and ARRAY-2. In this ‘case, neither 
ARRAY~1 nor. ARRAY-2 do not change. © . .. 


Target-Change-Type:  T changes its behavior, but M does not. 
This type of interaction often takes places to modify information stored in actors 
which behave like data structures. For example, 


[CELL cm (updete: AN] 
(LIMPURE-QUELE <n (enguione: BY] 


are of this type. The behavior of A or B do not change after the interactions. 


Message-Change-Type: M changes its behavior, but T does not.’ 
Examples of this type of interaction are initsited by: events such as: 


[sort <= ARRAY] 
[empty << IMPURE-QUEUE]. 
When an array-actor ARRAY is sent to the sort actor, the same array-actot ARRAY 
but the empty actor does not change its behavior. 


Bg 
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Target-Message-Change-Type: Both M and T change their behavior. 
Examples of this type of interaction are often found in situations where some 
information is removed from one actor and transfered to another. In Chapter 8, we 
will model the activities in a simple post office in terms of actors. The interaction 


among customer actors, collector actors, and a mail box actor in the model is of this 


type. 


4. Specifying Serial Computations 


In this chapter, our specification techniques for serial computations are presented. 
Since our model is so constructed that serial computation is naturally extended to parallel 
computation, most of the concepts, notations, conventions and techniques introduced in this 
chapter are not only valid but also necessary for the specification and verification of 
parallel computations. In the first section, we introduce basic tools for. describing the time 
variant behavior of actors. In the second section, we briefly discuss the role of conceptual 
representations in our model of computation. In the third section, our specification . 
language for serial computations is explained and some issues of specifications related to 
“side-effects” are discussed. In the fourth section, examples of specifications written in our 


language are given. 
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4.1 Capturing Time Variant Behavior of Actors . 


In order for a formal specification language to be effective for our model of 
computation, it must be able to describe the time variant behavior of actors. The ability of 
our specif ication language to deal with this aspect of actor behavior is based on concepts 


introduced in this section. 


4.1.1 History of Messages and States of Actors 


As we have seen in the previous chapter, one source of the time variant behavior. 
of. an actor is the history of computations initiated by. messages sent to the actor. If the 
_ whole past history of messages sent to an actor A is known, the subsequent behavior of A - 
in response to a given message should be predictable. Thus, it is desirable to know the 
history of messages to specify the behavior of A.. However, it is not practical to enumerate 
all possible histories of messages. Two actors with different past histories (sequences) of 
incoming messages sometimes show the same subsequent behavior. Thus we can partition 
the set of histories (sequences) of messages sent to A into equivalence classes according to 
the subsequent behavior of A. By such equivalence classes; we can define the notion of 
States of an actor. That is, the state of an actor A at a given point in time is defined as 
equivalence classes on the past histories (sequences) of messages sent to A.. If A is in the 
Same state at a different time, the subsequent behavior of A will be always the same. 

The state of an actor which behaves as an information storer is often defined by 
the contents of the stored information. For example, the state of a cell-actor C at a time is 
defined by the contents B of the cell. This definition of states isa special case of our 
definition by equivalence classes on past message histories. For the contents of the cell can 


be viewed as the most recent ‘update message (update: B). The (update: 8B) message 
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_ represents the class of histories (sequences) of ‘mextages sent to'C-which have an (updete: 8) 
as the most recent update INEST, =. 

Some kinds of states are not naturally expressed by the contents of stored 
information. For example, states of a data base which is being accessed by a number of 
concurrent processes are not expressed naturally by some sored information in the data 
base. The states where processes are updating or retrieving information is the data base 
may be expressed as certain monitoring mechanisms attached to the data base, but ct 
mechanisms are dependent on the implementation oft the date’ ‘bate. “When the states of a 
data base are defined externally i.c independently of triplementation},* our definition of 
states is quite useful. The state of an air line reservation sprem distussed in Chapter 6 and 
that of a post office in-Chapter 8 are ts states Of sectors whicly are accessed by 
concurrent processes. | : 

Equivatence relations which determine: states (Le. equivaterice. classes): are chosen 
according to the purposes and level of the detait‘of the: specification. States whith are 
different at some levels of the detail of the specification: may be the same at other levels. 

In Section 6.4, Chapter 6, we will discuss an alternative way of defining states of 
actors by continuous functions. 


4.1.2 Situations 


To incorporate the notion of states into the formalism for specification and. 
verif ication, we need a notion of sttuations. A situation is the teal state of an actor system 
at an instance of the local time! A notion of situations which assumes the global state and 
global time reference “has been proposed in ‘the area of Artificial 


1. We will discuss the local time in. detail in Section 61.2, Chapter 6. . 
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Intelligence[McCarthy-Hayes69, Hewitt75). Our medel of computation allows parallelism 
which is realized by concurrent message passing... Since .instances-ef concurrent message 
passing (i.e. events) may take place totally independently, it is quite-unnatural to assume the 
global time reference and global states of the system. [Local computations carried out by a 
PDP-i0 at CMU are irrelevant to computations carried out by a-PDP-l0:at Stanford even if 
two computers are connected through the ARPA network.) 
| In our formalism, states of actors and actor systems are always used with reference 
to situations. From this viewpoint, situations can be considered as references of the local — 
time. For example, the contents of a cell-actor C changes from time to time according tothe | 
‘update messages which have been most recently sent to C. Suppose that the contents of C 
is 3 in a situation S where C receives (update: 4) message. Then in the next situation 8’ 
where C receives the message (contents:), the contents of C is 4, (See Figure 4.1) 
By using a symbol § to denote a situation, we express the contents of C in the 


Situation in the following manner 


(contents C) = 3 is 8 


We call a symbol such as S, which is used to refer to a situation, a situational tag. . 
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Uses of situational tags considerably inctease. the expressive power of our 
formalism. For example, suppose -that we have two impure quewe-actors, queue-1 and 
queue-2, and that some event takes place ina situation Sire "Let Bost denote the 
Situation after that.event: ‘Then the question:and assertion-of whether or rot the ae of. 
quevent: is:ecaiatte that! of See ee is wneed:us Tollows: 


Mength —) = (length vez) in a 


By distributing the situational tag Boos the same statement can be made in the following 


two different ways: 


(length queve-1) in 8 sos:) = (Uength queve=2) ia B post! or 
Wongth (queve-2 in Bigg!) = Uength (queve-2 tn Sat) 


Since situational tags allow-us to relativize facts, relations between facts hokling in different 
Situations can be easily stated in our formalism. _ For example, an assertion that the length 
of queue-1 in. B post is greater than the length of overt in in B pre is is stated as: 


(length queue-1) i in + Bon) > Mength queve-1) in Sore 


This. kind of assertion is quite useful to show the termination of ala Furthermore a 
question « about the identity of the queues is easily stated as: 


(quever1 in S post) is-eq (queve-2 in Sore) 


Situations are f requently referred to as the time’ of message arrival, namely at the 
time when an event takes place. We use the following notations to refer to such-situations. 
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Sit <== MJ), Sit(cevent>) 


4.1.3 States, Identities and Conceptual Representations 


An actor may change its state f rom situation to situation and dif ferent actors may 
have the same state in the same situation. Thus, in developing a specification language, we 
must distinguish the state of an actor from its identity! 

In order to describe. states “of actors in our. specification language, we use 
conceptual representations introduced in Chapter 2. Identities of actors are expressed by 
Syntactic constructs different from conceptual representations. The most general form to 
express the fact that an <actor> has a state expressed by a <conceptual representation) in a 


<situation> is as follows. 
(<actor> is-2 <conceptual-representation») in. <situation> 


For example, suppose that the state of an impure queue-actor Q which has three elements A 


8 and C is expressed by a conceptual representation: 
(IM PURB-QUEUE [A 8 cn | 
Then the fact that Q has the above state in a diciattoe =} is expressed as 
(Q is-a (JM PURE-QUEUE [AB cy) in § 


- It is very important. that the role of conceptual representations in our specification 


1. We assume that the identity of an actor never changes. 
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language is to describe only states states of actors, but not to represent identities of actors. [When 
we introduced conceptual representations to give tormal specifications of data structures in 
Chapter 2, the separation of states from identities was not made clear.) 

| A predicate “is-a” is used to associate the sate of an. actor with its identity. In 
order to differentiate identities of actors, a predicate“ ie-eq” and its negation form “not-eq” 
are used. Since many attors may have the same state in the: same ‘situation, when the 


oe 


f ollowing assertion holds, 
. (Q’ isa. UM PURE-QURUE [AB SP)-in By 
it may or may not be the case that 
Q ts-eq QD. 

When the sharing of actors is involved, the separation of states from identities in 
the formalism considerably simplifies the process of keepitig’ tack of ‘changes in situations. 
For example, suppor. that two _Gifferent celFactors G and 4 contain the same impure. . 
queue-actor Q ina situation 8S. This is expressed as as: 

(G is-a (CELL (contents: Q))) 
. (H is-a (CLL means bibl 
(Q ine (MPURE-QUEUE [A B cn 


Then in the situation S, an | actor D is acc, at tthe rear ‘of Q. A description of the next 
situation 8” can be obtained simply by.changing the sate-of Qinto — 


(0 is-a (IMPURE-QUEUE [A 8 C DD) 
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and the assertions about G and H need not be modified! This is an example of our 
technique of manipulating assertions which will be discussed extensively in the next 


chapter. 


4.2 Types, Views and Conceptual Representations 


Before going into the details of our specification language, it would be interesting 
to consider the roles of conceptual representations in the actor model of computation. 

Actors are the only objects in the model of computation. Actors are untyped. We 
do not assume that actors are intrinsically classified into subcategories such as types and 
modes. There are two reasons for this. One is that actors are objects in an abstract model 
of computation, not ob jects in programming languages which often have types and modes 
for reasons of reliability and implementation efficiency. Another reason, which is more 
fundamental, is that we like to emphasize the behavioral view of actors. That is to say, we 
like to be able to use two actors interchangeably and indistinguishably as tong as they show 
the same behavior with respect to some purposes and environments where they are 
primarily used. Also the same-actor should be'able to behave quite-differently for diff erent 
purposes and in different environments. In. other words, we should be able to take a 
multiple view for individual actors. We believe that such muttiple: views encourage one to . 
employ flexible distribution of computing power ahd inteltigence such as potymorphic 
operators[Greif-Hewitt?5) and. the negotiation style’: programming using coroutines in 
writing programs for distributed systems{Yonezawa-Hewitt??] and Artificial Intelligence 


1. To insure the validity of these assertions in 8’, we need certain rules which will be 
discussed in Section 5.1.3, Chapter 5. © 
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research[Hewitt75]. Thus it seems beneficial to atlow a single actor to have a broad role 

which would bé narrowed by imposing a strict type on it. au 
Conceptual representations provide us with the means to express not ‘only states of 

actors, but also multiple views and summaries of behaviors Such views and summaries 


expressed by conceptual representations facilitate the understanding and implementation of 


the behavior of actors. 


4.3. A Specification Language 


In this section, we explain basic constructs of our specification language fo or serial 
computations arid also discuss some issues of the time variant behavior of actors related to 
specification languages. The specification language resented, in this section will be 
extended to include parallel cir in (Chapter i 


4.3.1 Specifications of Events 

A “specification” of an event is a formal description of effects: caused by an event 
which takes place in an. actor system.. Roughly: speaking, the-effects of an event E are 
described by the next event caused. by E and assertions which hoki in the situation where 
the next event takes place. The choice of the next event from the set of the subsequent 
events caused by E is determined by the level of detail.and the: purpese of the specification. - 

A general form of specification. for an: event: in our.spetification language is 
written in. the following notations: 
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<event: E 


(Case-i: 
<pre-cond: .. assertions ... > 
<caused-event: FE’ > 


<post-cond: assertions ... >) 


> 


E is the event whose effects are described. Since the effects of E may vary depending 
upon the situation where E takes place, the description of the effect may be divided into 
more than one case. The assertions in the <pre-cond:...> clause state the prerequisite which 
has to be satisfied in the situation where E takes place, When the prerequisite is satisfied, 
the event E’ in the <caused-event:..> clause always takes place and the assertions in the 


<post-cond: ...> clause hold in the situation where E’ takes place.- More formally, . 


for E, 
if <assertions-in-precond> in Sit(E) 
then 3E’ 


such that E --> E’ and <assertions-in-posicond) in Sit(E’) 


The prerequisite stated in each (Case-i:...) clause must be mutually exclusive. From this, the 
above notation can always specify the effects of an event deterministically. The <event: ...> 
clause need not contain all possible cases where E might take place. {In other words, the. 
logical union of the prerequisites for each case need not be universally true.) When E does 
not takes place in any of the stated cases, we assume that:the caused effects are undefined. 
The scope of names and variables in the above notation is always local to each (Case-i:..) 
clause. That is, the same names and variables in different (Case-i: ...) clauses do not have 


to refer to the same object. Names and variables appearing in the expression which 
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represents the event E are global to each (Case-i:...) clause. 
Though the above notation is broadly applicable, we often use abbreviated forms 
for events which initiate nested activities (cf. Section $1.3, COR: a Suppose that the 


_ poerlgits ooh a 


event E is of the form: 


[LT <x= (request: Mi replytd: co 


and the corresponding caused event E’ is of the form: 


— [Cc rend a. 


where R is the actor which is received by the continuation actor c in the message of & 
Then we my use the following abbreviated form: 


(Case-i: 
' <pre-cend: .. assertions ..> 
<return: R > 
<post-conid: .. assertions >) © 


> 


For example, the effects of an event where a-celt-actor C whieh has the contents B receives 
the retrieving message (contents:) is written using the abbreviated form as follow. [Note that 
there is only one case to be specified in this er : $0 the (Case-ts..) notation can be 
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<event: [C <= (contents:)] 
<pre-cond: (C is-a (CELL (contents: B))) > 
<return: B > 
<post-cond: (C is-a (CELL (contents: B)))>> 
Other abbreviated forms are obtained by omitting <pre-cond:...>, <caused-event:...?, 
<return:...> OY <post-cond:..> clauses. When an event has no prerequisite, the <pre-cond:...> 


clause may be omitted. For example, the creation of a cell-actor does not have any 


prerequisites. Its specification is written as follows: 


<event: [_create-cell <= A]] 
<return: C*® > 
<post-cond: (C is-a (CELL (contents: A)))>> 


where create-cell is an actor which creates a new cell-actor and A is its initial contents. 


In general, in our specification language, underlined words such as create-cell are 


constant symbols which always denote a fixed actor. Non-underlined words which denote 
an actor are free variables and can be used as pattern variables in the process of symbolic 
evaluation which we will discuss in the next chapter. The notation <actor>* means that an 
<actor> is newly created and is not is-eq (cf. Section 4.1.3) to other actors created before. 
When one is not interested in the assertions holding in a situation where the 
caused event takes place, the <post-cond:...> clause may be omitted. Furthermore when one is 
not interested in the caused event, the <caused-event:..> or <return: ..> clauses may be omitted 
too. For example, when the contents of a cell-actor is updated, what event is caused or » 
whether the caused event might take place or not are sometimes not important. In such 


cases, a specification of the update event may be written as follows. 
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<event: [C <= iepeaiess =A] eee 


<pre-cond: (C.isra, SCEIL Agamonts: BY), Ad 2. 
<post-cond: (C is-e (CELL (contents: AY ) 


4.3.2 Specifications of. Actors (Contracts) 


Every actor has. its own finite fixed set of message. types that it, can accept. For 
exemple: a cell-actor accepts two types of messages, (contents:) and, (update: <new-element>), — 
and a queue-actor accepts two types of messages, (nq: Gir aaa) and (dq:). A 
Specification of an actor A must contain the spelifications, ofan ‘events;-each of which is 
the receipt of one type of messages that A can accept. | on ‘should also contain the 
Specification of the event where A is created, if it is pombe to create A on 
computations. , a . 

As an example, let us specify the behavior of pure queue-actor (cf. Section 3.2.2, 
Chapter 3) in our specification language. irs, we describe the creation of a pure | 


queue-actor. 


<event: [ create-pure-queue <= [J] 
<return: c's > 
<post-cond: (Q is-a (PURE-QUEUE m) » 


This tells us s the following three things: 

I) A new pure queue-actor Q is created by a an event where the j oresle-puresausus actor 
receives an empty sequence actor fh 

2) The creation event has no prerequisite. 


3) States of a pure queue-actor is expressed by conceptual representations of the form: 
(PURE-QUEUK{...}) in the specification. 
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Next, we specify the enqueue event where a pure queue-actor receives (nq: <element>). 


<event: [Q <= (nq: A)] 
<pre-cond: (Q is-a (PURE-QUEUE tum) > 
. <return: aQ* > 
<post-cond: 
(QQ is-a. (PURE-QUEUE [4x A})) 
(Q is-a (PURE-QUEUE [8x})) >> 


This tells us that: 
1) A new pure queue-actor QQ is created and returned, 
2) A becomes the last element of QQ and the rest of .QQ’s elements are the same as those 
of Q, and 
3) The state of Q does not change. 
The specification of the dequeue event can be written in a similar way. 
In addition to specifications of events associated with an actor A being specified, 
the specification of A may include some related information which is necessary or helpful 
for using and understanding the specif ication. Definitions of ‘auxiliary conceptual 


"representations used in the specification, definitions of attributes or properties of -A and 


certain rules! concerning the validity of assertions used in the specification are examples of 


such information contained in the specification. In the case of a pure queue-actor, for 


example, the following definition of a property “length” may be given in the specification. 


<property: length-of(Q) = length{!x] 
where (Q is-c (PURE-QUEUE [ix})) > 


Length-of is the newly defined property of ‘a pure queue-actor and length is a function 


1. Such rules. will be explained in the next chapter. 
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predef ined on -conceptal sequences This definition sys that length-of of a pure 
queue-actor in a situation where its ‘states is expressed as rr} ie (PURE-QUEUE [!x})) is 
obtained by calculating length{!x] i’ 
We often use the term “contract” instead of « “pee “to emphasize the fact 
that it is an agreement or a “treaty” between the (eile ot of. an actor (module) and its 
designers or clients, and also between its bnplenahear’| wad? its “users. Users of a module M 
should rely only on properties stated in ‘the contrac of M. On the other hand, when 
implementors construct the module M, they are required to satisfy only what is stated in the 
contract of M. In the process of syribolic evalaation’of a progfath Which uses a module N, 
only properties of N which are derived fromthe contract of Nshould be used. In Figure 
_ 4.2, we give a contract of pure queue-actors. It should be noted that the scope of ‘names 
and variables in contracts are always local to specifications Of events, definitions, and rules. 
For example, Q in the first <event:.> clause in ‘Figuré: €2 does not ‘necearly denote the 
same actor as Q in the second <event:..> clause. : 


4.3.3. Validity of Assertions in i aielacacace “ 


There are. two important assumptions about assertion in ‘specifications of events. . 
One assumption is that states of actors which are not ‘explicitly stated in specif ications are 
unknown. That is, we assume that we do not know how an event E effects actors which are 
not mentioned in the specification of the event E. This assumption requires that effects of | 
an event should be stated in specifications as explicitly as ‘possible in accordance with the 
level of detail of the specifications. The other assumption, is. that assertions are usually . 
valid only in the situations where they are stated. If the state of an actor A is given in a — 


<pre-cond:...> clause of the specification of an event E and the state of A is not-given in the 


Fig. 4.2. A Contract for Pure Queues 


“Covent: [ereate-pure-queue ¢ {1} 
<return: Q*) 


<post-cond: (Q is-a (PURE-QUBUE {)) > > 


<event: [Q <= (ng: A)] 
<pre-cond: (Q is-a (PURE-QUEUE rp) > 
<return: 00* > 
<post-cond: 
(QQ is-~e (PURE-QUEUE [ix A))) - 
(Q is-a (PURE-QUEUE [ix})) > > 


<event: [Q <= (dq:)] 
(case-1: 
<pre-cond: (Q is-a (PURE-QUEUE [])) > 
<return: (exhausted:) > 
<post-cond: (Q is-a (PURE-QUEUE J) >). 


” (case-2: 
<pre-cond: (Q is-a (PURE-QUEBUE {[B §y})) > 
return: (dequeued: BB brent20Q")) > 
<post-cond: 
(QQ is-a (PURE-QUEUE [ly}): - 
(Q isa (PURE-QUBUE [B fy])) > > 


<property: length-of(Q) = longth{ix] 
where (Q is-a (PURE-QUEUE (xD) > 
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corresponding eect oaae > Clause, we assume that the. state. of A_after the event E is. 
unknown. It may or may not remain unchanged. For scala the state of a pure 
queue-actor after the enqueue event does ihot change”: ‘se gated inthe contract of pure 
queue-actors in Figure 4.2, the assertion about, the state of. a pure ‘queve-actor: 


(Q is-e (PURE-QUEUE eae = oe 


iS repeated in the <post-cond:..> clause. Since a pure queve-actor does not change its state 
after the creation [from the definition: of “purity’], this repetition<of the assertion may be 
superfiuous. But there is no way of knowing’ whettier Ot Hot the actor being specified is 
pure. Paid oie es 


4.4 Examples of Specifications 


In this section, several -other Characteristic examples: of specification (contracts) 
written in our specification language are given. “Some of the specifications given here are 


followed by the corresponding PLASMA implementations. =~ 


4.4.1 A Contract for Impure Queues 


In contrast to the contract for pure queue-actors in Figure 4.2, we give a contract 
for impure queue-actors in Figure 4.3. As discussed in Section 3.2.2, an impure queue-actor 
never creates a new queue-actor in response to (nq:...) or (dg:) messages: instead it changes its 


own state. 
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Fig. 4.3. A Contract for Impure Queues 


<event: [[create-impure-queve <= [J] 
<return: Q* > 


<post-conditions: (Q is-a (/MPURE-QUEUE [])) > > 


<event: [Q <= (nq: A)] 
<pre-conditions: (Q is-a ([MPURE-QUEUE tex > 
<return: Q > 


<post-conditions: (Q is-a (IMPURE-QUEUE [fx A])) >> 


<event: [[Q <= (dq:)]] 
(case-]: 
<pre-conditions: (Q is-a ([MPURE-QUEUE [])) > 
<return: (exhausted:) > 


<post-conditions: (Q is-a (IMPURE-QUEUE [])) >) 


(case-2: 
<pre-conditions: (Q is-a ([MPURE-QUEUE [B !y])) > 
<return: (dequeued: B (rest: Q)) > 
<post-conditions: (Q is-a (IM PURE-QUEUE {ty)) > » 


4.4.2 A Specification for a Message-Change Interaction 


As an example of specifications for the Message-Change Type interaction (cf. 


Section 3.2.4, Chapter 3), a contract for an actor which empties the elements of one impure 


queue-actor into another impure queue-actor is given in Figure 4.4. 


implementation of an actor which satisfies the contract above is given in Figure 4.5. This 


implementation will be verified against the above contract by the technique of symbolic 


evaluation in Chapter 5. 


6 = 
Fig. 4.4. A Contract for empty-one-queue-into-enother 
<event: [. empty-one-queve-into-enether < <= (Qi el 


(Q1 isa (/MPURE-QUEUE [i)) 
(Q2 is-a UMPURE-QUEUE [1x2))) 
(Q1 net-eq Q2) > : 

<return: (done: [Q1 Q2]) > 


<pest-cond: 
pia is-a (IM PURE-QUEUE om a 
LE [8x2 xd ))) >... 


Fig. 4.5. A PLASMA of empty-one-queue-inte-snother 


(empty-one-queue-into-another = 

(=> [=qi =q2] jtwo impure queues are seosived by emppty-one-queue-into-ancther 
sand bound to qi end q2. 

(rules (qi <= (dq:)) | tthe dequening message is sent to q1. 

(=> (exhausted:) if qi is empty, the complaint message is received 

(done: [q1 q2})) jthen emptied q1 and extended q2 are returned. 

(=> (dequeued: xtront-of-q1 iif qi- de. net empty, the front clement of qi and . 

(rest: =dequeved-qi)) sthe remaining queue ere received 

send bound to front-of-qi and dequeved-ql. 
(q2 <= (nq: front-ef-qi)) ee strent-ebqi is enquened et rear of .q2. 


(empty-one-queve-into-snother <= [dequeved-qi q2]})) ) )) 
' sdequeved-qi and q2 ere sent te empty-ene-queue-into-snother. 


Bie 
4.4.3 A Specification for a Target-Message-Change Interaction 


As an example of specifications for the Target-Message-Change Type interaction 
(cf. Section 3.2.4, Chapter 3), we give a specification for an interaction between a vender 
who sells some goods and a customer who buys the goods. The state of a vender who has 
some amount of money and goods with him is expressed by conceptual representations of 


the form 
(VENDER (bills: {...}\ (goods: {...})) 


The state of a customer who is carrying some amount of money and belongings is expressed 


by conceptual representations of the form 
(CUSTOMER (bills: {...})(belongings: {...})) 


Their interaction is described by the event specification in Figure 4.6. 


Fig. 4.6.. A Specification for an Interaction Between a Vender and a Customer 


<event: [V «= c] 
<pre-cond: 
-(V is-a (VENDER (bills: {4bs}) (goods: {8g §s}))) 
(C is-a (CUSTOMER (bills: {ibe §m}) (belongings: {§p})))> 
<return: C > 
<post-cond: 
(V is-a (VENDER (bills: {8bs Im}) (goods: {1g}))) 
(C is-a (CUSTOMER (bills: {!be}) (belongings: {8p §s}))) 
(worth[{!s] = total-amount[!m]) >> 


4.4.4 Contracts for Generators 


A generator is an actor which behaves like a sequence of the possible answers to 
some problem. When it receives a “(next:) message, a next answer ‘is generated. As 
examples, we consider two actors which successively generate increasing squares. One isa 
pure generator-actor, called a “port-of-squares", and the other is an impure one, called a 
“stream of squares”. A contract for each generator is given in Figure 4.7 and Figure 48. In 
the first event specifications in both contracts, | and u denote the lower bound and the 
upper bound, respectively. 


Fig. 4.7. A Contract for Port-of-Squares 


<event: [create-port-of squares es <= [i vil j 
<pre-cond: (1 ¢ u) >. 
<return: PS* > 
' <post-cond: (PS is-a (PORT-OF-SQUARES (lew: |) (high: u))) >> 


<event: [PS <= (next:)] 
(Case-1: 
<pre-cond: (PS is-a le ca aia (lew: k) ee k))) > 
“return: (exhgusted:) > - 
<post-cond: (PS is-a (PORT-OF -SQUARES (leew: k) (high: k))) >) 


(Case-2: 

<pre-cond: 
(PS is-a (PORT-OF-SQUARES Gow: 9) igh: 7) 
(<u) > 

<return: [I? PSS*] > 

<post-cond: 
(PSS is-a (PORT-OF-SQUARES Uew: | + 1) thigh: u))) 
(PS ie: (PORT-OF-SQUARES Uow |) Udghi wAP)}> 
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Fig. 4.8. A Contract for Stream-of-Squares 


<event: [create-stream-of-squares <= [i uJ] 
<pre-cond: (I$ u)> 
<return: SS* > . ; 
| <post-cond: (SS is-a (STREAM-OF-SQUARES (low: |) (high: u))) >> 


<event: [SS <= (next:)] 

(Case-}: 
<pre-cond: ($$ is-a (STREAM-OF. ~SQUARES (low: k) (high: k))) > 
“return: (exhausted:) > 
<post-cond: (SS is-a (STREAM-OF-SQUARES Wome k) (high: k))) >) 


‘ (Case-2: 
<pre-cond: ; 
(SS is-@ (STREAM-OF-SQUARES (low: |) (high: u))) 
(I <u) > 
<return: [l2 $$) > 
<post~-cond: 
(SS is-a (STREAM-OF-SQUARES ow: | + 1) thigh: u))) >) > 


4.4.5 A Contract for average 


In this subsection, we give a contract for acters: whose behavior depends directly on 
the history of incoming messages. Obviously such actors are impure, An example given 
here is a contract for the “average”. actor, whigh: retugns the. average of: all the numbers 
which nave been sent to it. The contract is given in Figure49.. 

The conceptual representation (AVERAGE [..]) for the. actor explicity. represents 
the history (sequence) of aff the fumbets which have been received by the actor. This idea 
is similar to that of Clint973) who has intraduced a:“reythizal- pushdown stack" to have the 
history recorded as a kind of comments in program texts to aid the. verification of 
programs. The function average-of in the contract in Figure 49 is defined on conceptual 


sequences. 


Fig. 4.9. A Contract for average 


<event: [create-average <= I] 
<return: A*® > 


<post-cond: (A is-a (AVERAGE [1)))) >> 


<event: [[A <= (new-element: N)} 
<pre-cond: (A is-a (AVERAGE [ix})) > 
<returm: A > 
<post-cond: (A is-a (AVERAGE [%x N})) >> 


<event: [A <= (average:)] 
<pre-cond: (A is-a (AVERAGE [ix})) > 
<return: average-ol[?x} > 
<post-cond: (A is-a (AVERAGE [8x))) >> 
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4.5 Relationship to Other Work 


At this point in our exposition, it would be useful to discuss our specification 


techniques for serial computation in relation to other work in this area. 


4.5.1 Behavioral Specifications 


Based on the actor model of computation, I. Greif and C. Hewitt [Greif-Hewitt75, 
Greif 75] have developed the behavioral approach to the specification technique. In their 
approach, the behavior of an actor (or an actor system) is specif ied in the form of axiom 
about events and the precedes order relation. Axioms describe the kinds of events that can 
or must take place and the order in which these events can or must occur. Axioms describe 
conditions which must be satisfied by computations. 

This approach can deal with the time variant behavior of actors and parallelism, 
but makes no use of the notion of states of an actor A [which we have defined as 
equivalence classes of messages sent to A). Therefore, for example, in writing axioms which 
Specify responses to a message sent to A, the previous history of computations of A must be 
written out explicitly, The lack of the notion of states in their approach makes 
specifications long and difficult to understand. In particular, axioms for the behavior of 
impure actors which behave like data structures tend to be very complicated and unnatural. 
(Imagine the axioms for impure queue-actors.) The reader of such specifications of a data 
structure could understand only through reinterpreting axioms in terms of his intuitive 
notion of states of the data structure. In our approach, states of actors play the central roles 
in specifications and they are described by conceptual representations concisely, clearly and 


yet rigorously. 


4.5.2 Burstall’s Work 


By extending Floyd-Hoare{Floyd67, Hoare69) approach, R. Burstall{i972) has 
proposed some specif ication and verification techniques which are able to deal with list 
processing languages with “side-effect” primitives such as rplaca and rplacd. To cope with 
the problem of side-effects in list structures, he uses a special notation for linear list 


Structures. For example, a list structure: 


x - y 
I | 
I I 
t---> {FT ---4> CT) SS) 


is expressed in his notation as follows. 
Gx => y -P-F-> il) 


Though one might find some similarity between Burstail’s notations and those based upon 
conceptual representations, it is difficult to accommodate his notations to a wide variety of 


data structures. 


4.5.3 Rich and Shrobe’s Work 


C. Rich and H. Shrobe have developed a specif ication language for LISP which is 
used in their LISP understanding syster(Rich-Shrobe’®] In their system, the reasoning 
techniques used to deal with the problem of side-effects in LISP are along the same lines as 
ours. However, the clear separation of identities of objects from states of objects (cf. 
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Section 4.1.3) is not realized in their Formalism. Thus specif ications in their language tend 
to be long and are difficult to use for other programming languages. For example, let us 
look at an example of specification given in [Rich-Shrobe76] 


(S pec-for: SWAP 
(input: PAIR-1) 
(Output: PAIR-2) 
(Assert: 
(1D PAIR-1 PAIR-2) 
(LEFT PAIR-2 [RIGHT PAIR=1)) 
(RIGHT PAIR-i [LEFT PAIR-1)))) 
SWAP operates on a LISP pair to exchange its left element and right element. No new pairs 
are created by this operation. In the specification above, names PAER~1 and PAIR-2 denote 
the same pair object P, which is stated by the first assertion in the (Assert:..) clause. The 
reason why they need to use two different names for the one object P is to distinguish the 
State of P before the operation from that of P after the operation. In our specification 
language the SWAP operation can be written without introducing a different name for P. 
Using a conceptual representation which describes the state of a pair ob ject, a specification 


for SWAP is given as follows. 


<event: [[ SWAP <= P] 
<pre-cond: (P is-a (PAIR (left: A) (right: B))) > 
<post-cond: (P is-e (PAIR (left: 8) (right: A) >> 


4.5.4 Floyd-Hoare Approach 


The traditional Floyd- Hoare approachiFloyd6?, Hoare69, Hoare?2, Igarashi-et-al75, 
Suzuki75) to the specification and verification of programs has been limited in its ability to 
deal with programs which change their behavior. For example, the sharing of data 
structures in simple ALGOL-like languages is difficult to treat?” “Suppose that in the 
following code x and y are two- and one-dimensional arrays, respectively. 


y « x{3, }; el. . 9p sllee of x ts shared by y. 
x{3, 4] © xf3, 4} + 15. 


Their assignment rule cannot derive the correct value of y{4] after the above code is 
executed. The reason is that the value (ie: sate) of an program variable is not 
distinguished from its identity. , 

Furthermore, the lack of the separation of states from identities makes it difficult 
for their approach to deal with specification and: verification of programs written in 
SIMULA-like object-oriented languages. For example, ‘thelr formalism is inadequate to 
deal with the following simple piece of SIMULA code: - 


queue-1 : - new creste-impure-queuel); | 
queue-2 : - queve~1 .enqueue(2); 
queve-2.enqueve(3);. 


In the next chapter we will demonstrate haw this kind-of cade is treated in-our formalism. 


1. In the traditional Floyd-Hoare approach, variables in assertions denote literal program 
variables. Thus the value of a program variable should be considered as its state. 
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4.5.5 Algebraic Specification Techniques 


As discussed in Section 2.4.1, Chapter 2, algebraic techniques [Zilles74, Guttag75) 
have been developed for the specification of abstract data types{Liskov-Zilles74]. In the’ 
algebraic approach, all operations and procedures are specified as functions, which leads to 
a serious problem; the purity and impurity (cf. Section 3.2.1, Chapter 8) of data structures 
cannot be easily distinguished. 

_ As an example, let us consider an algebraic specification of queues given in 
(Guttag75]. Important operations on a queue are ADD and REMOVE, whose functionality is 


as follows. 


ADD: Queue x Integer ----> Queue 
REMOVE : Queue ---> Queue 


The essential part of the specification is given by the following equation: 
REMOVE(ADD(q, i)) = ADD(REMOVE(Q), i) (*) 


where q is not an empty queue. In their interpretation, operations such as ADD and REMOVE 
always create new ob jects and cause no side-effects to the objects that they operate on. 
Equations of operations such as (*) define congruence relations over the word algebra 
constructed from the operations and objects. Thus in their approach, algebraic techniques 
_are used to specify the behavior-of only pure actors (immutable ob jects). 

There is another interpretation. If we consider the domain and range of 
Operations as sets of states of objects, equations (axioms) of the operations can define 
congruence relations over the states of objects. In this interpretation, algebraic techniques 


can be used only for impure actors (mutable ob jects) 
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In either interpretation, the algebraic approach has difficulties in dealing with 
both pure actors and impure actors simultaneously. Techniques developed by J. Spitzen 
and B. Wegbreit (Spitzen-Wegbreit?5, Wegbreit-Spitsen76}-have the same problem of 
distinguishing the purity and impurity of data structures. 


- 87 - 


5. Verifying Serial Computations 


In this chapter, our verification techniques for serial computations are presented. 
The first section describes the method of symbolic evaluation which is the major 
instrument in our verification techniques. It also contains a detailed explanation of our 
reasoning method which can be employed in environments where computations may cause 
side-effects. The next two sections describe our verification methods, each of which is 
applied to different types of actors. Then, to close the chapter, we reflect on our method of 


symbolic evaluation and discuss its application to other areas. 


5.1 Symbolic Evaluation 


In this section, we will describe our basic method of symbolic evaluation, the ma jor 
instrument of our verification techniques. A simple example of symbolic evaluation of 
PLASMA code which involves sharing of actors with side-effects is given at the eo of the 
section. Although in this thesis we consider ‘symbolic evaluation primarily asa tool for 
program verification, it is also useful for other purposes such as program testing, 
debugging, optimization, dependency analysis, perturbation analysis etc. The chapter 


concludes with a discussion of some potential applications. 


5.1.1 Overview 


Symbolic evaluation is a process which abstractly [symbolically] executes programs 
on abstract (symbolic, as opposed to “concrete"] data. When a program takes numerical 
input, the symbolic evaluation of the program does not deal with concrete numbers such as 
123, 1776, and 1984, but rather with symbolically expressed numbers such as “nl”, "n2", and 


m". 
Though symbolic evaluation is an extension of ordinary execution of programs, it 
differs from ordinary execution in the following points. 
| (1) The only properties of input that can be used are-the ones. specificed as the . 
prerequisites of a module being symbolically evaluated. [Eg., input numbers are 
required to be positive integers.) 
(2) When the.symbolic evaluation of a.medule M encounters an invocation of some 
module N, the specification. [contract] of Nis. used to. continue the symbolic 
evaluation. The implementation of N is not used. 


- 89- 


Symbolic evaluation can be viewed as a mechanization of the process of a human 
programmer tracing a program without using concrete values to understand the 
computations expressed by the program. 

In symbolic evaluation, the code of a module is interpreted step by step according 
to either pre-defined semantics of language primitives or specifications of modules invoked 
in the module. Each such step is triggered by the symbolic evaluation of an expression in 
the code which corresponds to an event [cf. Section 3.1.2, Chapter 3]. The state of the » 
program [code] at each moment before and after an interpretation step is referred to as a 
situation. The symbolic evaluator! has a data base to record what events occur, what facts 
hold and what is assumed in each situation. Facts that hold in a situation & are recorded 
as assertions associated with S. 

Since each expression is interpreted on abstract data, when a conditional expression 
is interpreted, the subsequent symbolic execution path must split in the usual, 


fashion[Deutch 1973]. For example, consider the symbolic evaluation of 
if (P x) then ... else .... 


After the symbolic evaluation of the expression (P x), the symbolic execution path splits into 
two branches: one for the then-clause and the other for the else-clause. To start the 
subsequent symbolic evaluation, (P x) must be assumed for the then-clause and -(P x) for 
the else-clause. If the evaluation of (P x) has no side-effects, the assertions holding in the . 
situation where (P x) is evaluated are inherited for both clauses. 


In essence, symboiic evaluation is a process which abstractly evaluates the code 


1. In this chapter, we assume that symbolic evaluation is carried out by a hypothetical 
system. 


Fig. 5.1. A Situational Tree 


forward along the execution path and produces a-tree structure ‘whose nodes correspond to 


Situations. At each node of the tree, assertions which hold in the corresponding: situations 
are entered. We call this structure a situational tree.-{See. Figure 51.) The assertions 
entered in the situational. tree are used as. the primary source of infermation for answering 
questions about the implementation. As we shall later see, verification of implementations is 


carried out by using such situational trees. 


5.1.2 Partial Descriptions of Situations 


In order to illustrate how assertions. are handled in a -situational tree, we 


symbolically evaluate the following piece of code. 


-s- 
(queve-1 <= (nq: 6)) squeve-1 receives a message (nq: 6) 
(queue-1 <= (nq: 8)) squeuerl receives a message (nq: 8) 
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S, S’, and S” denote situations before or after the events corresponding to 
Statements in the code. We assume that two distinct impure queues, queve-1 and queue-2 
have been created before the situation & and assertions about states of the two queues are 


already entered at the node for S in a situational tree. See the diagram below. . 


| 

S: (queve-1 is-a ([MPURE-QUEUE [3 7 11])) 

|  (queue=2 is-a (1M PURE-QUEUE (2 4))) 

| 
With these assumptions, the first statement in the code which expresses an event 
[ queue-i <= (nq: 6)] is interpreted. To know what effects are caused by this event, the 


symbolic evaluator first looks for an assertions about the state of queve-1 at the node for & 


in the situational tree. It finds that the state [or conceptual type] of queve-1 is expressed as 
(1M PURE-QUEUE [3 7 11)) 


' From the form of the conceptual representation [i.e., from “/MPURE-QUEUE’], the contract 
for impure queues in Figure 5.2 is referred to. | 

‘The event expression [.Q <= (nq: A)]] in the second <event:..> clause in the contract 
for impure queues in Figure 5.2 matches against the event [queve-1 <= (ng: 6)]]. Also the 


assertion 
(Q is-a (1M PURE-QUEUE [$x})) 
in the <event:...> clause matches against the assertion 
(queue-1 is-a ([MPURE-QUEUE [3 7 11))) 


which has been entered at the node for S. Thus the whole second <event:..> clause can be 


instantiated as follows. 
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Fig. 5.2. A Contract for Impure Queues 


<event: [create-impure-queve «(J 
<return: Q* > 


<post-cend: (Q is-c (J/MPURE-QUBUE {)) > > 


<event: [Q <= (nq: A)] 
<pre-cond: (Q is-e (IMPURE-QUEUE [ix})) > 
<return: Q > 
<post-cond: (Q is-a (JM PURE-QUEUE {ie an > 


<event: [Q <= (dq:)] 
(case-1: 
<pre-cond: i is-a (1M PURE-QUEUE [})) > 
“return: (exhausted:) > 
<pest-cond: (Q is-e (1M PURE-QUEUE [])) >) 


(case-2: 
<pre-cond: (Q is-e (LM PURE-QUEUE {B fy])) > 
<return: (dequeued: B (rest: Q)) > 
<post-cond: (Q is-a (1M PURE-QUEUE [ly])) > > 


<event: [ queue-1 <= (nq: 6)] 
<pre-cond: (queve-1 is-a (1M PURE-QUEUE (3 7 11)))> 


<return: queve-1 > 

<post-cond: (queve-1 is-a (1MPURE-QUEUE [3 7 11 6)))>> 
The symbolic evaluator enters the assertion in the above <post-cond:..> clause at the node . 
for the next situation 8’. Also it records what event took place between the two situations. 
See the upper diagram in Figure 5.3. The second statement in the code expresses an event 
[queue-1 <= (nq: 8)]], which is interpreted in the same way as above. The effect of this 


event is recorded at the node for the next situation 8” as shown in the lower diagram of 
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Figure 5.3. 

An important point in the manipulation of assertions described above is that the 
assertion about the other impure queue actor, queue=2, is left untouched, neither copied nor 
modified in going from & to S’ and S”. As the diagrams in Figures 5.3 show, the 
situational tree thus generated by the symbolic evaluation does not contain assertions about 


the states of queue-2 at the nodes for 8’ and S”. In general, a situational tree generated 


Fig. 5.3. 


8 
S : (queue-1 is-a (J/MfPURE-QUEUE (3 7 11))) 
|  (queue-2 is-a (J/MPURE-QUEUE [2 4))) 
| 
[ queue-1 <= (nq: 6)]] 
| ” 
S’ : (queve-i is-a (JM PURE-QUEUE [3 7 11 6))) 


3 : Gaiek is-a (IM PURE-QUEUE [3 7 11))) 

| (queue-2 is-a (IM PURE-QUEUE [2 4))) 
ae <= (nq: 6)]] 

s° : (queue-1 is-a (IM PURE-QUEUE (3 7 11 6))) 
ised <= (nq: 8)]] 

s° : (queue-1 is-a (/MPURE-QUEUE [3 7 11 6 8))) 
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by symbolic evaluation is only a partial description of situations. When one needs to know 
States of actors or relations hokding in a situation, which are net-explicitly asserted at the 
corresponding node in the situational tree, one must rely on the reasoning method described 


in the next subsection. 


5.1.3 The Method of Reasoning (Uses of the Trans-situational Rules) 


In this subsection, we will illustrate how situational trees are used for the reasoning 
in ae ormalism. In general, questions about a given stration are answered by reasoning 
backward. That is, to answer questions such as ‘whether ‘some assertions hold in a situation 
S or in what states some actors are in S, a situational tree is looked at from the node for S 
to previous situations. 

For example, suppose that a Situational tree. shown in Figure 5.4 is.given and we 
want to know the state of Q in a situation 8,. First we try to find some assertion which 
describes the state of Q at the node for the situation 87. Since the given situational tree 
does not have any assertions about Q at the node for 7, we look for assertions about Q_ 
backward along the branch of the situational tree. [See the dotted line in Figure 5.4.) An 


assertion 
(Q is-a (JM PURE-QUEBUE [2 5 4))) 


is found at the node for S3. However, all we know at this point is that the assertion holds 

‘in S&S . but we are not sure that the assertion holds in 8, because some events which 
destroy the validity of this assertion in Sy might have occured between $4 and &,. So we 
must check on such events. 


In order to know what events nullify the validity of assertion, each event 


Fig. 5.4. Reasoning Backward 


83: (Q is-a (IMPURE-QUEUE [2 4 5})) 


85 8, 


6 8, 


‘specification in the contract for impure queues shown in Figure 5.2 is examined. If in the 
specification for an event E the state of Q stated in the <pre-cond:..» clause is different from 
the one in the corresponding <post-cond:..> clause, the event E nullifies the validity of the 
assertion. In fact, [Q <e (dq:)] and [Q <= (ng:..)] turn out to be such nullifying events. 
The process of finding the nullifying events can be saved if the contract contains 
an explicit statement which indicates such events. For this purpose, we may add the 


following clause to the contract for impure queues! 


<for-assertion: (Q is-a (1M PURE-QUEUE [...})) 
<only-affecting-events-are: 
{[Q <= (nq: J, [Q <@ (dq:)J} »> 
This statement says that the validity of assertions of the form 


(Q is-a (IMPURE-QUEUE {[...)) 


I. <for-assertion:..> clauses do not have to be placed in contracts for actors. They can.be 
placed in some global place to which the symbolic evaluator have access. 
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is destroyed only by the set of events appearing in the <only-affecting.> clause.” 


In our formalism, assertions of the form 


(<actor> is-a <conceptusi-representation>) 


can be inherited from an ancestor situation 8; to a descendant situation § j if the following 
two conditions are met: . 
(I) The events specified in the corresponding <for~assertion:.> clause. do not take 
place between 5; and 8. . 
(2) At the node for the descendant situation 8, no assertions about the <actor> 
have been entered which use the same form of conceptual. representation as used in 
the assertion being inherited from §&,. 

By virtue of the secend condition, we.do nat have to keep adding events to the 
<for-assertion...> Clause every time we implement a new. actor which changes the state of the 
<actor>. For example, suppose that an actor. emplying-queve which empties. the elements of 
an impure queue-actor is implemented and that its specification is given as follows: 

<event: [ emptying-queue <= QJ 

<pre-cond: (Q is-a ({M PURE-QUEUE [!x))> 

<post-cond: (Q is-a (JM PURE-QUBL/E {J}: 
When the PLASMA expression (omptyingrqueue- <e Q) is syrpbolically interpreted in a 
situation §& where (Qis-a (1M PURE-QUEUE Qi 2 3p) holds, the assertion 
(Q is-a (1A1 PURE-QUEUE m0) is entered at the node for the next ‘gaan 8”. If we did not © 
have the above condition (2), the assertion (Qi is-a (IMPURE-QUEUE [1 2 3])) could be 


2. Note that this reasoning is valid only for serial computations. It is not valid if there are. 
concurrent events. see . | ier 
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inherited to S’. To prevent this invalid inheritance without the condition (2), we would 


need to add the event [[ emptying-queve <= Q] to the list of nullifying events. 


In general, the rule which indicates what conditions guarantee valid inheritances of 
assertions from one situation to another is called a trans-situational rule. For particular 
assertions or particular forms of assertions, appropriate, trans-situational rules are necessary 
for correct reasoning. The <for-assertion:..> clauses given in contracts are one type of 
trans-situational rules. In Section 5.1.5, tone examples of trans-situational rules are listed. 
The reasoning using trans-situational rules described here is a procedural approach to 
McCarthy's frame problem [McCarthy-Hayes69] We will discuss this issue in Section 5.4. 


5.41.4 Variables and Identifiers 


In this subsection, we will explain how names for actors are handled in symbolic 
evaluation for programs written in PLASMA. The technique given here allows us to deal 
efficiently with the problem of both identity and sharing of actors. 

Names in PLASMA fail into two classes: variables and identifiers. A variable x 
can be declared and also initialized with the-value of an expression <E1> by the following 


form of statements 
| (let (x initially <E4))...) 
The value of x can be changed only by executing expressions of the form. 
(x © <E2>). | 


Occurrences of x in programs except in the above form stand for the value of x. A 


variable x is usually implemented by a cell acter, but in that case an expression x in code 
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does not stand for the cell actor itself, but rather for the contents of the cell actor. In 


symbolic evaluation, to. state that a <varisble> has an Gector> as its Value in some situation, 


assertions of the following form are used. | 
| (<varlable> has-velue <actor>) 
When the symbolic evaluator interprets an expression 
x « ©). 
in a situation S, the following assertion — 
(x has-value B) 


is entered at the node for the next situation, where B is the value of <= in 8S. - 
An identifier is declared and bound to an actor in the course of program 
execution. To express that an <identifier> is bound to an <ector>, we use assertions of the 


form 
(<identifier> = <ector>) 

In the symbolic evaluation of a module M, an identifier x used in the code of M can be 
always regarded as the actor that it is bound. to, because one identifier is:not bound to more 
than one actor throughout the symbolic evaluation of M. This is guaranteed: by: © 

(1) the restriction on the syntax of PLASMA that no names are declared more than 

once inside a module, and | 

(2) the fact that symbolic evaluation passes over each expression in a module 


exactly once! 


l. This fact is true only. when symbolic evaluation is used for program verification. 
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When more than one symbol [here, symbols mean ones denoting actors in contracts 
(such as Q in Figure 5.2) as well as indentifiers in programs] denotes the same actor, we use 


assertions of the form 
(<symbol-1> is-eq <symbol-2>) 


As an identifier can be regarded as the actor that it is bound to, the relation “is-eq" and "=" 
can be used indistinguishably. Since the relation “is-eq” is an equivalence relation, it forms 
an equivalence class of identifiers in programs and symbols denoting actors in contracts. 
Every member of such an equivalence class denotes the same actor. In symbolic evaluation, 
one identifier (or symbol) is chosen from each class [e.g., the one which is first used among 
the members of the class] and any uses or occurrences of other members in the same class 
are always considered as those of the chosen one. To record the state of an actor A, the 
symbolic evaluator always uses the one chosen identifier or symbol for A throughout all the 
Situations. This arrangement eases the handling of shared actors in symbolic evaluation. 
To illustrate the use of identifiers and symbols explained above, let us consider 
the following piece of code. This code is a PLASMA version of the SIMULA code given 


in Section 4.5.4, Chapter 4 as an example which is difficult for the Floyd-Hoare technique. 


-So- 
(let (queue-1 = (create-impure-queue )) 
then -S,- 
(let (queue-2 = (queue-1 <= (ng: 2))) 
then -8o.- 
(queue-2 <= (nq: 3)) 
-S3- 


So,...S 3 denote situations before or after the events corresponding to statements in the 
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code. In what follows, the notation 
in 8: Assertion. 
means that <assertion>s are entered at the node for 8 in a situational tree. . 
The event [create-impure-queve <= [J] takes pice in Sp. By virtue of the 
contract for impure queues in Figure 5.2, we know an empty. angers, queue-actor is created. 


Then the let statement binds the identifier queve-1 to the empty queue-actor. We _may use 
a symbol Q for the newly created actor and record this event by two assertions 


(Q is-a (IM PURE-QUEUE [))) 
(queve-}. =.Q), 


but one assertion suffices. Namely, 
in S,: (queue-i is-o (JM PURE-QUEUE {})). 


‘The second statement of the above PLASMA code is antes bree by using the 


f olawing event specifi ication instantiated from the clause in the contract for impure queues 


<event: [ queve-1 <= ae 2yy 
<pre-cond: (queue-i is-a (1M PURE-QUEUE [}))> 
“return: queue-1 > 


<post-cond: (queue-1 is-a (JM PURE-QUEUE [2})}>> 
The state of queue-1 is changed as described by the assertion in the <post-cond:..> clause. 
and queue-1 is returned. The let statement tells us that-the returned queve+i- is bound to 


queve-2. Thus . fe - 


in Bo: (queve-1 is-a (JM PURE-QUEUE (2})) 
(queverl is-eq queve-2) 
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In interpreting the third statement, since we know that queuve-2 and queue-1 denote 
the same impure actor, the event [queue-2 <= (nq: 3)] stands for [queve-1 <= (nq: 3)]. 


Thus the change in the state of queue-1 is recorded as 
in $3: (queuve-1 is-a (1M PURE-QUEUE [2 3})) 


Any references to queue-2 in the interpretation of the subsequent statements in the code are 


treated as the references to queue-1. 


5.1.5 Examples of Trans-Situational Rules 


In this subsection, we will give the trans-situational rules which will be used in the 


examples of symbolic evaluation in this thesis 


(:) Assertions of the form (<identitier> = <actor>) 
which state that <identifier> is bound to <actor>, can be passed unchanged between any two 


situations within the scope of <identifier>. 


(:) Assertions of the form (<actor1> is-eq <actor2>) and (<actor1> not-eq <actor2>), 
which state the identity of actors, can be always inherited from one situation to another 


without any conditions. : 


(:)  Assertions of the form 

(<c-sequencei> = <c-sequence2>).and (<e-sequencei>  <e-sequence2>), 
which state the equality of conceptual sequences appearing in conceptual representations, 
can also be inherited without any conditions. [Note that <cesequencel> and <c-sequence2> 


are not sequence-actors but mathematical sequences. All mathematical facts can be 
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inherited without any conditions. This is a special case.) 


(2) Assertions of the form (<actor> is-a (SEQUENCE {x})) 
which state that <actor> is a sequence-actor whose elements are fx, can be inherited without 


any conditions because a sequence-actor is a pure actor which never changes its state, 


(x) Assertions of the form (<variable> has-value <ector>) . 

which state that <variable> has <actor> as its value in some situation gs, can be inherited to a 
situation T if no assignments to this <variable> take place between 8 and T. (Cf. Section 
5.1.4.) | 


5.2 Verification of Actors Behaving as Procedures 


Methods of verification reflect methods of specification. Roughly speaking, two 
methods have been employed in the specification technique presented in the previous 
chapter. pe ne ee | 

One method is to specify the behavior of an actor A in terms of the states or the 
changes in the state of other actors which are sent to A, or which are created during the 
invocations of A. In this method, the state of A is not used in specifying the. behavior of 
A. Most actors which behave purely. as “procedures” are specified by this method. A 
typical example of such actors is empty-one-queue-into-another. [See Section 4.4.2, Chapter . 
4.] In general, this method applies to the specifications of the attors which are targets in 
the No-Change-Type and Sento le émeractions introduced in Section 3.2.4, 
Chapter 3. SS 

The other method is to specify the behavior of an actor B in terms of the changes 
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in the state of B itself. Actors which behave as “information storage”, such as data 
structures and generators, are specified by this method. 

In this section, we will illustrate our verification techniques for actors behaving like 
procedures, whose behaviors are specified by the first method mentioned above. The 
verification techniques corresponding to the second specification method will be discussed 
in the next section. However, since actors are essentially procedural objects whose 
implementations are written as programs, most of the techniques that will be discussed in 
this section {such as the handling of recursion, loop, case splitting and convergence) are 


necessary bases for the verification of information-storage-like actors. 


5.2.1 Symbolic Evaluation in the Context of Specifications 


In order to verify an implementation of an actor against its specification, symbolic 
evaluation of the implementation [i.e. code or script) is carried out in the context of the 
specification. In our formalism, a specification of an actor which behaves like a procedure 
is expressed by a specification of the event which initiates the invocation of the actor. A 
specification consists of the preconditions for the incoming message [i.e. input), and the 
postconditions to be satisfied by the result of the invocation. Thus the symbolic evaluation 
of the implementation is started with the assumption that the preconditions are satisfied. 
Under this assumption the symbolic evaluation is carried out and then the results of the 
symbolic evaluation are examined as to whether they satisfy the postconditions given in the 
specification. | 

Below we will demonstrate the verification of an implementation of 
empty-one-queue-into-another [hereafter empty) against its contract. Its contract and 


PLASMA code are given in Figure 5.5. The code is augmented with situational symbols 
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_ Fig. 5.5. A Contract and Implementation of empty-one-queue-into-snother 
<event: [ empty-one-queve-into-another,<7:[01 021} 


<pre-cond: 
(Q1-ts-c (FAT PURE-QUEUE [11))) 
- (Q2 dea. LIM PURE-QUEUE Ex2)) 
(Q1 not-eq Q2) > a 
<return: (done: [01 az) > 
<post-cond: 
{Q1 is-a (IMPURE-QUEUE Oo 
2 is-a (MPURE-QUEUE Led aM » 


(empty-one-queve-into-another = 
(=> [=ql =q2] jtwo impure queues are received by empty-one-queve-into-another 
sand qi and q2 are bound te them. 


. 5 -eceived-queves a 
(rules (qi <= (dq:)) jthe-dequening message is sent to qi. 
(=> (exheusted:) if qi is empty, the complaint message is generated 
é S oxhausted-qi * ss 3, : : 
(done: {qi q2]) ) _ gthen emptied qi and extended q2 ere returned. 
(=> (next: =fronteof-qi vf qt is not empty, front-of-q1 
(reat: =dequeued-ql)) . _. .. gemd dequeued-ql 


jare bound to the a element of at and the reremrene queue, respectively. 

- 5 dequeued-qi ~ 
(q2 <= (nq: front-of-qi)) front-ofeqi is enqueued at rear of q2. . 
> S enqueved-q2 . 


(empty-one-queue-into-another <= [dequaued-qi q2))).).)) 
. sdequeved-qi and q2 are sent te empty-one-queve-into-another. 
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which denote situations before/after events corresponding to each statement. Note that this 
implementation contains a conditional branch and a recursion, the handling of which will 


be explained below. 


First, the preconditions of empty in its contract are entered in the data base. 


in Sinitia : 
(Q1 is-a (IM PURE-QUEUE [#x1])) 
(Q2 is-a (JM PURE-QUEUE [1x2])) 


{Q1 not-eq Q2) 


After the symbolic pattern matching is performed, identifiers qi and q2 are bound to Qi 


and Q2, respectively. So this is recorded in the data base as the following assertions. 


in S eceived-queues ; 
(qi = Q1) 


(q2 = Q2) 


Then the PLASMA expression (q1 <= (dq:)) in the rules-statement is interpreted. The 
dequeuing message (dq:) is sent to Q1 that qi is bound to. To know the result of this 
event, the symbolic evaluator must consult the <event..> clause for the dequeuing in the 


contract: 


<event: [Q1 <= (dq:)] 

(case-]: 
<pre-cond: (Q1 is-a (IM PURE-QUEUE [])) > 
«return: (exhausted:) > 
<post-cond: (Q1 is-a (1M PURE-QUEUE [])) > ) 

{case-2: 
<pre-cond: (Q1 is-a (JMPURE-QUEUE [B fy])) > 
<return: (next: B (rest: Q1)) > 
<post-cond: (Q1 is-a (IM PURE-QUEUE [!y])) >) > 
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(Note that the above clause is an instantiation of the <event..> clause for the dequeuing in 
the contract for impure queues in Figure 5.2, which is obtained by substituting Qi for Q.} 
Now the symbolic evaluator has to consider two cases: where Qi is empty and where Qi is 


not empty. (See the situational tree for this example in Figure 56.) 


Case I: (QI ise (IMPURE-QUEUE ()) 


In this case, the contract specifies that the (exhansted:) message should be returned. This 
message matches against the first (=>..)-statement inside the (rules..) statement. To follow 
this path, x1 = [] must be assumed. So at the node for B oxneusted-q1’ the following 


assertions are entered. 


in 5 exhausted-qi s 
(x1 = []) 


(Q1 is-a (JM PURE-QUEUE [})) 
Then the result of the invocation, the message (done: [qi q2)), is returned in 8 axhausted-qi- 


For this result, there are three. postconditions stated in the contract of empty: 


Fig. 5.6. 
i ‘ 
5 -eceived-queues 


Zs ai 
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ri: (done: [Qi Q2}) must be returned 
r2: (Q1 is-a (JM PURE-QUEUE [})) must hold, and 
r3: (Q2 is-a (IMPURE-QUEUE [1x2 Ix1))) must hold. 


It is easy to show that each postcondition is satisfied. in B axhausted-qi: 
(3) for ri, since the trans-situational rules for pinding allow the inheritance of the 


assertions (qi = Q1) and (q2 = Q2) from 8 to S 


diet eckad 
the required message is returned in: ‘B ghausted-qi" 

(«) for r2, the assertion (Q1.is-¢ ([MPURE-QUEUE ain is entered at the node for 
s 


exhausted-q1' 


exhausted-qi' and 
(«) for r3, the two facts guarantee that the requirement is satisfied: 
(I) (2 is-a (IM PURE-QUEUE [8x2])) can be inherited from Sjpitia) t© 
S exhausted-qi DY using the trans-situational rule for — | 
(Q2 is-a (IMPURE-QUEUE {..})) [which is obtained. by instantiating the 
<for-assertion:...> Clause in the contract for impure queues. Cf. Section 5.1.3.]. 
This inheritance is legitimate because neither Coz ro ings: J onor 
[02 <= (dq:)] have happended and no assertions of the form 
(Q2 is-a' (IM PURE-QUEUE [...]))” have been entered at the node for 


S eo xhausted-qi- 


(2). [tx2] = [fx2 fxi] holds in Baxhausted-q1 because x1 = [] holds in 
Soxhausted-qi° ( [8x2 bet] © [x2 i{)) = (tx2] ) 


Thereore (Q2 is-a (IMPURE-QUEUE [!x2 {x1]})) holds in Bernantedat Thus Case-l is 


verified. 
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se-2: (Qi is-a {(M PURE-QUBUR fb bv) 


In this case, the contract for ampure queues tells us that rent: B (rest: Qi) is the result of 


. (qi <= es: )) where the following assertions are ssalined. 


(x1 = [B fy) 
(Q1 is-a UM PURB-QUBUE lp) 
The result (next: B resis Q1)) is matched against the.pattern.in.the-second (=>...) statement 
"inside the (rules...) Statement. At the nade for: ssaueued-qi’ the Binding information is 
also entered together with the above assumption. . 


in S gequeued-qi $ 

(tront-of-qi. = B) 

(dequeved-qi = Q1) 

(x1 = [8 8y)) 

(Qi is-a UNECE ty) 
Then the PLASMA expression (ee Ls (ng tront-of-a1)) is interpreted in this situation. 
Since q2 is bound to Q, and front-of-q1 is bound to B {from the trans-situational rule for the 
binding], the event taking place is Cr « (ng: 83. To. know. the effects of this event, the 
system refers to the second <event:..> clause in the contract for impure queues in Figure 5.2. 
The state of Q2. in 5 sequeve-ql is obtained, from “the assertion 
(Q2 is-a (IM PURE-QUEUE {#x2])) at the node for Bag: Berquse it can be inherited to 
B dequeved-qi for the same reason as ‘explained above in the case of its inheritance from 
Sinitiat © Sgequevedeqi:. "hus the second: <event:..> clause is instantiated as follows. [Note 
the substitutions of Q2 for Q, x2 for x and B for A] 
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<event: [Q2 <= (ng: B)] 
<pre-cond: (Q2 is-a (JM{PURE-QUEUE [{x2])) > 
<return: Q2> 
<post-cond: (Q2 is-a (1M PURE-QUEUE [!x2 B])) >> 


The assertion in the <post-cond:..> clause is entered at the node for 5 enqueued-q2° 


in Senqueued-q2? (02 ise (/MPURE-QUEUE [!x2 B})) 


Now the last PLASMA statement (empty <= [dequeue-qi q2]) is interpreted. From the 
binding information, the corresponding event is [ empty <= [Q1 Q2]]. To know the effects 
of this event, the contract for empty in Figure 5.5 is referred to. Since we are trying to 
verify the code against this contract, this is a “recursive” use of the contract. The 
preconditions stated in this contract must be satisfied before it can be used. In fact, the 


assertions: 


(Qi is-a (JM PURE-QUEUE [y})) and (Qi not~eq Q2) 


can be inherited from 5 dequeued-qi by the trans-situational rules for 


(Q1 is-a (IM PURE-QUEUE [...])) and (<actor1> not-eq <actor2>), 


respectively. Thus the following assertions hold in 5 enqueve-q2 


(Q1 is-a (1M PURE-QUEUE [#y]))) 
(Q2 is-a (1M PURE-QUEUE [!x2 B))) 
{Q1 not-eq Q2) 


Therefore the preconditions of empty are satisfied. Now the postconditions of the contract 


for empty guarantee that (done: [Q1 Q2)) is returned and that the following assertions: 


J. Recursion and iteration in symbolic evaluation are discussed in Appendix III. 


-HO- 
(Q1 is-a (IMPURE-QUEUE [])) and 
(Q2 is-a (1M PURE-QUEUE [S[8x2 B) fy))) hold. 
hold in the situation following 8 pasuediq? Facts'abbut c-sequences: 
(8{8x2 B) fy) = [x2 B fy), : 
[4x2 B ty) = [Ex2 txt], if x1 = [B ty} 
"are used to simplify. the above assertions. That is, since xi = [8 ty) can be inherited from 


8B dequeved-qi by the trans-situational rule for Mereoquance ty = CeveequenceZ>}, it follows 
that 


(Qi is-a (UM PURE-QUEUE Mm 7 
(Q2 is-a (Mf. PURE-QUEUE (hx2 pap). 
Thus the hina for emoty-one-aimuninornotar 8 are also satisfied in Case-2. 


Though it has been shown that both Case-i and Case-2 meet the postconditions for 
empty, we cannot conclude that the implementation of empty in Figure 55 satisf ies its 
contract, because the convergence of the invecition’ of ‘the implementation is not 
guaranteed, although it is: explicitly required By the ‘contract. fRecall the meaning of 
<return:..> Clauses given in the previous chapter For after. splitting into two cases at the 
(rules...) statement, the symbolic evaluation for both Case-].and.Case-2 isiresumed under the 

assumption that the control has reached the points corresponding to 5 exhausted-qi and 
S dequeved-qi- Therefore, to demonstrate that the above ‘asnimption is always, guaranteed 
is another part of the verification process. This issue is discussed in: Appendix Iv. 
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5.3 Verification of Actors Behaving as Information Storage 


In this section, we will present our specification techniques for actors whose 
behaviors are specified in terms of their own states [or changes in their own states): 
Specifications of actors which behave as “information storage” such as data structures and 
generators [Section 4.4.4] are often written in terms of their own states. For the verification 
of implementations of these actors, symbolic evaluation is still the major instrument and all 
the techniques presented in the previous section are still employed. In addition, however, 


special considerations are necessary in dealing with conceptual sepresentations of the actors 


being v@rified. We will discuss such considerations in the next subsection. 


5.3.1 Implementation Invariants 


The specification of impure queue actors in Figure 5.2 is written in terms of the 
changes in their states before and after their invocations, and their states are expressed by 


Ad 
conceptual representations of the following form. 


(1M PURE-QUEUE [...]) 


When some program which contains invocations of impure queue actors is symbolically 
evaluated, conceptual representations of the above form are used only to record states of the 
impure queue actors. One need not pay attention to what those conceptual representations | 
really stand for, as long as they represent the states of the impure queue actors at the 
conceptual level. However, when an implementation [script or code] of an impure queue 
actor Q itself is verified against its specification, what the conceptual representation 


expresses in terms of the implementation, or more precisely, how the state of Q expressed by 
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the conceptual representation corresponds to the states of the constituents of its 
implementation, must be considered. | | 

Suppose that the PLASMA: implementation of an impure queue actor given in 
Figure 5.7 is to be verified against the contract in Figure 3.2. In ‘this implementation, the 
elements of the queue are kept as the elements of a sequence actor that is the value of the 
variable queuees. This could be expressed: by the diagram in Figure 5:8, where’ boxes’ 
represent actors and arrows express the know-about relation’. This diagram is only a 
partial and. static. description of the. implementation, yet it iHustrates an invariant or 


Fig. 5.7. A PLASMA Timplementation of an Trapure Queue Actor 


(create-impure-queue = 


(=> [] screate-impure-queve receives an empty sequence. 

Get (queuees initially []) ga variable quevees is declared 

then jand initialised snith an empty. sequence. 

(the-queue-itself = ya quene-actor denoted by the-queve-itself is defined 

a) Gas - gby she caves-statement given below. 

(cases 

(=> (nq: =new-element) when an énquoue ‘message with an demént is veceiand: 

_ jrew-shement ts bound to the element. 

(quevees + [Squevees new-element)) je new sequence-ector whose elements are 

 3thé abpath-of the value of quevees and new-element 

jis created ane weed in quevees. 

the-queue-itself) | finan 6° ‘Is retus 

(=> (dq:) “ohen e dequene message ie received, 
(rules queunes i ee = sif the value of queuées . 

=> [] (exhausted:) ) ” is empty, then the message is returned. 

(=> [=front larest) if it is @ non-empty sequence, front and rest 

7 jare bound to its first element and the rest of its elements, respectively. 

(quevees + rest) - - phe. udles of quevets is updated. 


(next: front (rest: tharquoveritaot »» » , Beoxt:...) is returned. 
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integrity condition which must be satisfied among constituents of the.implementation. The 
following implementation invariant statement can express the diagram more formally. 


<I mplementation-Inveriant: 
if (the-queue-itself is-a (IM PURE-QUEUE [la))) 
then 
(queuees has-velue S) 
(S is-@ (SEQUENCE [fa))) > 
This says: when the state of the actor denoted by the-queueciteelf is expressed by the 


conceptual representation — 
(IM PURE-QUEUE [la)), 


the variable queuees has the value which is always some ‘sequence actor $-whose elements 
are expressed by [fa]. (SEQUENCE [1s}) is the conceptual representation for such a sequence 


Fig. 5.8. 
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actor. 
An implementation invariant describes the mapping from the states of an actor 
(the "specification space")-to the states of the constituents of a giver implementation for the 
actor (the “implementation space”)! Suppose that the behavior of an actor A is specif ied by 
the state of A before or after its invocation, Then an implementation invariant is used in 


the verification of A in the following way. 


First, the state S of A before the invocation is translated into the state II(S) of the 
constituents of the _tmiprementation by a given implementation invariant Il. Then the 
implementation [code] is symbolically evaluated and the states of the constituents af ter, 

the invocation are obtained. Next, by using the imiprenencation invariant again, the 
state S’ of A, specified as the one after the invocation, is translated into the state II(S’) 

. Of the constituents. . Finally, the states of ‘the constituents: obtained by the symbolic 

evaluation are checked to see if they satisfy those translated states. [See Figure 5.9.) 

In-general, given a state T of an actor A and an implementation I for A, an 
implementation invariant for I tells us the relations which must be satisfied by the states of 
the constituents of I to realize the state T. Therefore implementation invariants may be 
one-to-many mappings. In such a case, when symbolic evaluation of an implementation is 
started, only such relations (holding among the states of the constituents of an 
implementations) are assumed: exact states of each constituent are not used. An example of 
the one-to-many mapping cases is found in Section 7.4.2, Chapter 7. Implementation 
invariants are similar to the inverse of Hoare's abstract functions (Hoare72], and also serve | 


as concrete (representation) invariants which he used additionally in proving correctness of 


1. A state in the implementation space isa vector of states of the constituents of the 
implementation. 
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Fig. 5.9. Verification of an actor A Behaving like Information Storage 


<Invocation> 


P< 


s’ 


<Implementation Invariant> 


<S pecification S pace> 


Semen meee merronemememarowasdee nese coe soon 


<implementation S pace> 


ymbolic evaluation> Se 
@ 


IK(S) II(S’) 


representations of data structures. /nterpretation functions between two formal theories 


studied by R. Nakajima (Nakajima-et-al77] seem closely related to implementation 


invariants. 


5.3.2 Establishing Event Specifications 


An implementation of an actor which behaves as “information storage” is verified 


by establishing each event specif ication associated with the actor. In this subsection, we will 


illustrate this by using an impure queue-actor as an example. 
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The verif ication of the implementation of an impure queue-actor is carried out by 
. symbolic evaluation. “To aid in the exposition of the symbolic evaluation, we augment the 
PLASMA code in Figure 5.7 with situational symbols as shown in Figure 5.10. This code is 
verif ied against the contract in Figure 5.2. Below we will establish the two <event:..> clauses 
in the contract, which specify the creation and enqneiene events. The dequeuing event 
can be established similarly 


Establishin ? rION gpecificati 
Establishing the & CREATION specification 


In the first <event:. » clause in the contract in Figure 52: 


<event: ' [create-impure-queue <= (J 
<returns: Q*) > 


<post-cond: (Q is-a UCR EYE ph », 
there are no pre-conditions for ‘this event. Thus no ‘arveriods are entered in the data base 


for the initial situation. 


in 5 ore-crestion : empty 


The let statement in the-code declares and initializes a variable quevees with an empty 
sequence NS. . To_record: this, the following assertions are-ernfered. - 


in 5 initistized-quevees $ 
(quevees has-value NS) 


_ (NS is-a (SEQUENCE [))) 
Then in this situation an actor whose script (i.e. code) is given as the (coses...) statement 
after (the-queue-itseH =... is-newly created and returned. This actor is denoted by 
the-queue-itself; The contract for the creation requites two’ things: (1) that the returned 
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Fig. 5.10. 
(create-impure-queue = 
(>[] sereate-impure-queue receives an empty sequence. 
(let (quevees initially []) 3a variable quevees is declared 
then ; jand initialized with an empty sequence. 
ic S initistized-quevees e no _— 
(the-queue-itself = 3a queue-actor denoted by the-queue-itself is defined 
by the cases-statement given below. 
(cases , 
(=> (nq: =new-element) swhen an enqueue message with an element is received, 
snew-element is bound to the element. 
-§ é 


received-nq ~ 

(queuees + [!quevees new-element)) ja new sequence-actor whose elements 

sare the unpock of the value of quevees and new-element 
jis created and is stored in quevees. 


- 5 updated-quevees-nq 7 
the-queuve-itself) sand then the-queve-itself is returned. 
(=> (dq:) swhen an dequeue message is received, 
m 5 peceived-dq e 
(rules queuees 3if the value of quevees 
. (= [J sis an empty sequence, 
5 ompty-quevees . . 
- (exhausted:) ) sthan the complaint. message is returned. 
(=> [=front !=rest) uf it is a non-empty sequence, front and rest 
sare bound to its first element and the rest of its elements, respectively. 
= Snon-empty-quevees es << . a 
(queuees & rest) sthe value of queuees is updated. 
: 5 updated-quevees-dq - 


(dequeued: frant (reat: the-queve-itself)) ) ) ) ») 3(next:...) is returned. 
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actor Q be newly created and (2) that (Q is-a (JMPURE-QUEUE [})) holds. Since the 
returned actor is  the-queue-itself, what we need to show is that 
(the-queue-itself is-o (JM PURE-QUEVE [})) holds. This assertion is translated ‘into the 
following assertions using the assertions in the where-clause in the implementation invariant 
statement given in the previous subsection. [Note that the assertions in the where-clause 
are instantiated by substituting an empty sequence [] for fa.) | 

(quevees has-value S) | 

(S de-a ee bail 
These two assertions are matched against the two assertions entered at the node for 
S initiatized-quevees|  Therefore-it is concluded that the returned-actor the-queue-tteelf has 
the correct ‘internal structure Prescribed by the ‘implementation invariant. So the result of 


the event [ creste-impure-queve <= [J] meets its specification. 
"Establishing the ENQUEUING specification 
From the instantiation of the event specification for enqueueing: 


<event: [[ the-queve-itself <= (ng: A)] 
<pre-cond: (the-queye-itself is-a (JM PURE-QUEUE [Ix})) > 
<returns: the-queve-itselt > ad 
<posi-cond: (the-queue-iteelt isa (JM PURE-QUEUE (Ix A))) >> _ 


which is obtained by ‘substituting ° the-queue-iteel{ for Q in the contract for 

UM PURE-QUEUK ‘e )) in Figure 5.2, it is assumed that 
(the-queve-itself isa (JM PURE-QUEUE [1x})) 

holds in the initial situation. By the amnplementacton invariant SPEER, Cirle Saeunpuor is 

translated into the following two assertions: “ (Note that x is substituted for a in the 
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invariant statement.) 


in S; 


initialized-queuees * 
(quevees has-value S)) 


(S is-a (SEQUENCE [!x))) 
Now the message (nq: A) is sent to the-queue-itself. This message matches against the first 


clause of the case statement. So new-element is bound to A. 


in S receivedeng: (new-element = A) 


Then the value of queuees is updated by a newly created sequence-actor NS with its 


elements [queuees new-element]. The value of queuvees in S is obtained by 


received-nq 


inheriting from S because no updating events took place between the two 


initialized-queuees’ 
situations. Thus the value is a sequence-actor S. Iqueuees is the result of the unpack 
operation on S, which is #x. [Note that the sequence actor is pure. Therefore its state can be 


inherited from S. 


initialized-queuees"! So the state of the new sequence-actor NS is expressed 


by (SEQUENCE [i A]}). For the assignment of NS to queuees, the new assertion 
(queuees has-value NS) is entered in the data base. So the following assertions hold in the 


next situation. 


in 5 updated-queuees-nq ; 
(queuees has-velue NS) 
(NS is-a (SEQUENCE [!x A))) 


The code tells us that the-queue-itself is returned in this situation. The specification for the 


" nqueuing requires that the-queue-itself be returned and that 


(the-queue-itself is-a (1M PURE-QUEUE [fx A))). 
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So-this assertion is translated into the following assertions by the implementation invariant. 


(queuees has-value $) 
(S is-a (SEQUENCE [$x A))) 
These assertions are obviously matched against the assertions entered at the node for 


S Updated-queuees-nq. 5° the enqueuing event meets its specification. 


5.4 Discussions Related to Symbolic Evaluation: 


The method of symbolic evaluation presented in this chapter has many interesting 
facets and significant-implications for other research areas besides program verification. In 
this section, we first reflect on our approach to verification based-ow:spmbolic evaluation in 
the light of other existing approaches. We then’ discuss ‘the applications of symbolic 
evaluation. Finally, our reasoning method employed in = evaluation ‘will be 
discussed in the context of meer frame oe . ’ 


5.4.1 Situational Descriptions vs. Predicate Transformations 


Program verification methods based on the Floyd-Hoare Proof rules [Floyd67, 
Hoare69) or predicate transformers (Manna69, Di Jesra) cin ‘be summarized 2 as follows: 


Given a set of predicates P holding in a situation B, the proof * rules or the predicate 


transformer gerierate a set of predicates Pp [from PI which hold in the next! situation 


1. For the case of the proof rules, the next situation is the temporal successor situation, and 
for Dijkstra’s predicate transformers, it:is: the predecesser: situation, 
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S’ 
The choice of predicates holding in S determines the generated set of predicates for S”. 
Those choices are made so that desired assertions may be shown to hold in S”. This 


approach is schematically described in Figure 511. Note that the predicate transformers 


work backwards. 


Fig. 5.11. Floyd-Hoare-Di jkstra Predicate Transformation Approach 


<Proof Rules> 
<Dijkstra's Predicate Transformer> 


predicates , predicates 
holding holding 
in s 
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In contrast to the approach above, our approach is: 


* Given a. description D of a situation 5, symbolic evaluation. produces a description D' 
of the [forwardly] next situation by using contracts and trans-situational rules. 
A description ofa situation is:a collection: of assertions about states‘of actors which are 


expressed by conceptual representations. Predicates which hold in a situation ate derived 


from the description of the situation. This approach, which we call the “situational 
description” approach, is schematically described in Figure 5.12. 

Conceptual ‘Tepresentations not only express states of individyal actors in a system, 
but they can also describe how the individual actors are interrelated at various levels. Thus 
the description of situations in terms of conceptual representations is powerful in dealing 
with sharing. Furthermore, descriptions of each situation provide us with sources of 
various information abaut a program, which. is quite useful for other applications in the 


“areas of mechanical program analysis. 


5.4.2 Applications of Symbolic Evaluation — 


Symbotic evaluation based on formalisms different from ours has been studied for 
various purposes such as proving properties of programs [Boyer-Moore?5} program testing 
and debugging ([Boyer-et-al?75, King76), program transformation and improvement 
[Burstall-Darlington75] etc. 

Our method of symbolic evaluation can be used in constructing a software system 
called a Programming ‘Apprentice {Hewitt-Smith75, Rich-Shrobe?6}, which aids expert 
programmers in various aspects of programming activities such as verification, debugging, 


and refinement of programs. In the Programming Apprentice, the purpose of symbolic 


= 123 = 


Fig. 5.12. The Situational Description Approach 


PREDICATES PREDICATES 
holding holding 
in § in s'‘ 


CONTRACTS 
TRANS-SITUATIONAL RULES 


description of s' 
in terms of conceptual 
representations 


description of S 
in terms of conceptual 
representations 


<EVENT> aoe Gag 
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evaluation is not simply to verify stoetaind. agains their specifications. By symbolic 
evaluation, we try to gather information about dependencies between program modules.: 
Such information is used to understand implications of proposed changes in both 
Specifications and implementations in the subsequent evolutional development of the 
programs. . 


For instance, suppose that the implementation of # another used 


as an example of program verification is sent pure queue actors ‘eaten of impure queue 
actors. Using the contracts for puré queue actors in Figure 4.2 in Chapter 4, our fnethod of 
‘symbolic evaluation can easily trace and record. the behavior of the implémentation. The 
situational tree produced. during _ the symbolic. evaluation. aids us in modifying the 
implementation so that it may accept both impure and pure“ queue actors. Another simple 
example might be the analysis of the behavior of the same implementation when it is sent 
the same aMpure actor. {That is, one of the preconditions, (Qi not-eq Q2) is forgotten] 
Furthermore, as reported in (Yonezawa-Hewitt76) the 4ff iciency of the implementation of 
impure queue actors in terms of consumed storage can be revealed by tie assertions of 
the farm 
(<actor-1> knews-ebout <ector2>) 

in the process of symbolic evaluation. 

The situational description approach based on our method of ‘symbolic evaluation 
appears to be quite powerf ul m pursuing these ends. The symbolic: evaluator in C. Rich 
and H. Shrobe’s system (Rich-Shrobe76], which aneernens LISP programs is based on a- 


method similar tours. 
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5.4.3 The Frame Problem 


In the context of Artificial Intelligence, J. McCarthy and P. Hayes 
(McCarthy-Hayes69] pointed out a problem, called the frame problem, which arises in 
formalizing effects of actions or events taking place in a complex world. A typical example 
of the frame problem is found in formalizing the effects of actions of a robot in a block 
world where the robot carries out various physical tasks. Suppose that the robot has moved 
a block B to a certain location. With this action, the location of B changes, but most of the 
properties of the blocks, such as color, height, and volume, and relations holding among 
other blocks, do not change. To formalize the action “move”, it is necessary to specify not 
only which of these properties and relations will change [and how they will change], but 
also which properties or relations will not change. Since the robot is supposed to perform a 
number of different actions, for each action such changes in properties and relations in 
both positive and negative sense must be specified. In most cases, rather a small number of 
properties and relations change as the result of a single action, while the rest of them do 
not. Thus the number of such specifications will be unbearably large for a practical system 
if the tasks of the robot and the world in which it works become complicated. 

The same problem arises in the context of program specification and verification. 
In particular, the frame problem becomes serious when one tries to construct program 
verification or understanding systems which must deal with actors whose behavior may 
change with time. To specify the effects of computations [or events), the no-changes as well: 
as the changes in the states of objects in a system must be described even if the objects do 
not participate in the computations. If we described the changes and no-changes of all the 
ob jects in the system in a straightforward way, the same serious problem would arise. 

As presented in the first section in this chapter [5.1.2, 5.1.3), we take a procedural 


approach to this problem. Our reasoning method based on trans-situational rules is 
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powerful in coping with the problem in the domain of Artificial Intelligence as well. R. 
Waldinger has independently proposed an approach similar to ours for dealing with certain 
issues in program synthesis and has discussed its application to Artificial Intelligence 
[Waldinger77]. Those who are interested in comparative studies of the existing approaches 


to the frame problem should see [Sandwall72, Hayes73, Hewitt?5, Waldinger77]. 
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6. Specifying Parallel Computations 


In this chapter, the specification language introduced in Chapter 4 is extended to 
cover parallel computation. Formal specifications of abstract data type objects which are 
used in multi-process environments are written in the extended language. Examples for . 
illustrating our specification techniques include air line reservation systems and bounded 
buffers. An alternative definition of states of actor (ob jects) is discussed at the end of the 


chapter. 
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6.1 Introduction 


In this section, we will discuss the characterisitics of parallel computation which 
make its specification method different from that for serial computation. Our specification 
techniques for parallel computations will be described in the subsequent sections of this 


chapter. ai : 


6.1.1 Communicating Parallel Processes 


In a serial computation, activations of actors take place sequentially and one ata 
time. Thus it is modelled as a set of linear ordered events with each event causally related 
to one another. [Recall the definition of computations in Chapter 3.) In a parallel 
computation, however, more than one activation may take place concurrently. Some events 
are causally related to. each other, but some may not be. Therefore, a computation is 
modelled as a set of partially ordered events. A sequence of causally related events can be 
viewed as a "process". From this view point, parallel computations involve multiple 
processes and serial computations a single process. 

If, in a parallel computation, concurrent processes do not interact with each other, 
i.e., no events are causally related between processes, the computation can be viewed as a 
collection of mutually independent serial computations. 

However, there are many reasons for the necessity of interaction between 
concurrently running processes: If arguments in a procedure call are evaluated in parallel, 
a process which executes the procedure body must wait until all the parallel evaluations of 
the arguments are completed. In air line reservation systems and inventory control systems, 
concurrent processes interact with each other by retrieving and updating various 


information in data bases. In operating systems, concurrent processes interact through 
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sharing resources such as main/secondary memories and I/O peripherals. 

In order for such interactions [or cooperations) to be effective and efficient, 
concurrent processes must communicate and synchronize with: each other. Therefore in 
specif ying interesting behaviors of parallel computations, we need techniques which are 
able to deal with communication and synchronization between processes. In our model of 
computation, such communication and synchronization is realized by changing states of 
certain actors. actors. icetis, buffers and data bases are examples of such actors) Therefore the 
central issue in the method for specification of parallel computations is to deal with the 
behavior of actors which are used for communication and synchronization. 

States of actors are extensively used in specif ying paralte compara as well as 
Serial computations. But states of actors in parallel computations for multi-processor 
environments] need to be dealt with much more carefully than those in pace computations. 


We will discuss this issue in detail in ~ next subsection. 


6.1.2 Local States 


In describing behaviors of parallel computations, ‘there have been many 
attempts[Milner73, Kahn74, Ashcroft?5, Cohen75, “Owicki75, Keller, Owicki-Gries76, 
Flon-Suzuki77, Lamport77] to use the notion of the global states of an entire system. The 
global state of a system at a given time is expressed’ essentially by a vector of states of the 
subsystems. The use of the global states is often motivated by the use of non-deterministic 
serial computations for the semantic model for parallel computations. In order to study 
properties of a subsystem, this approach leads to counter-intuitive serialization of 


concurrent events taking ‘place in“untelated subsystems and it forces us to consider not only 
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changes in other subsystems but also the order in which such changes take place. Thus the 
number of cases to be examined tends to be exponentially large, but almost all changes in 
other subsystems are irrelevant to the subsystem under consideration. 

In our approach, we do not rely on such notions as the oe state and the global 
clock [unif orm time reference}. Rather we » take a Jocal and | ¢ view. We assume 
only the local states of individual actors. [er. Section 18, Chapoer 1 The local state of an 
actor is determined only at the local time associated with the actor. Thus when the state of 
a computer at some site of a computer network is determined, we do ‘not assume that the 
states of computers at other sites can be defined. ‘The state of an ‘actor is determined at the 
time when the actor receives a message. This timing i particularly important and usef ul in 
parallel computations because it is a well defined moment in a distributed system. (The 
moments of message transmission at scattered computer sites are difficult a compare, with 
each other.) Recall that the ordering of arrival of messages with respect toa given | actor 
{arrival subordering) is total in our model of computation. (er. Section 313, Chapter 3] 

In Section 4.1.1, Chapter 4, we have defined states of an actor as equivalence classes 
of past histories of messages sent to the actor. As discussed before, this definition 
subsumes, in serial computations, traditional definitions for data-storing’ ob jects, whose 
states are determined by their current information content, Such traditional definitions are 
inadequate in parallel computations (or multi-process.environmenta] For example, imagine 
a data base system which is concurrently accessed by a number of-users. If the state of the. 
data base wets defined as its stored data, its state at the time of the arrival .of an access 
request could not be determined, because the stored information, might be being changed by 
previously arrived requests. Also determining the, information content inside the data base. 
at the time when a request arrives at the data base is incompatible with our relativistic view 


introduced above. (imagine a data base system where an access request may. be received by 
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a computer site located at one side of the continent while actual data may stored at the 
other side.] | 

States of an actor defined as equivalence classes of the past message histories are 
not affected by the actual activations of the actor. Also the order of arrival of messages is 
linear (total). These two facts are essential to our specification techniques for parallel 
computations because they guarantee that states thus defined are always well defined even 
if the actor is being activated by the previously arrived messages. In the later sections, 
examples that illustrate the significance of our state definition will be found. In particular, 
a model of interaction between a post office and customers in Chapter 8 will provide an 


intuitive example. 


6.2 Extending the Specification Language 


Specifications of the behavior of actors in parallel computations are written in a 
way similar to that in which the behavior of actors in serial computations is specified. 
That is, when given the state of an.actor, the behavior. of the actor is specified by the 
resulting state changes and the subsequently caused events, However, the ma jor dif ference 
lies-in how the states of actors change and ‘how. such: changes are expressed. To distinguish 
such difference, the specification language introduced for. serial computations in chapter 4 


needs to be extended. 
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6.2.1 Instantancous State Changes 


Let us try to write a formal specification of a cell actor. A cell actor is used to store 
information. It accepts updating messages of the form (update: <new-contents>) and 
retrieving messages of the form (contents:). Its behavior is expressed informally as follows: 

"In response to a (contents:) message, 
a cell actor returns <contents> which was contained 


in the most recently arrived (update:.. .) message if such a message exists, 
otherwise it returns its initial contents” 


We would like to express this behavior by using the states of the cell! To express a 
state of a cell actor, we use conceptual representations. For example, 
(CELL (contents: A)) 
expresses the state which is defined as a class of histories of messages whose most recent 
updating message is of the form (update: A). If the cell were used only in serial 


computations, we could specify this behavior by the following two event specifications: 


<event: [C <= (contents:)] 
<pre-cond: (C is-a (CELL (contents: A))) > 
<return: A> 
<post-cond: (C is-a (CELL (contents: A))) > > 


<erent: [C <= (update: B)] 
<pre-cond: (C is-a (CELL (contents: A))) > 
<return: B > 
<post-cond: (C is-a (CELL (contents: B))) > > 


Unfortunately, the above event specifications do not precisely express the behavior of a cell 


in parallel computations, because the states of C expressed in the <post-cond:..> clauses are 


1. I. Greif and C. Hewitt gave a specification of cells which is expressed by axioms about 
events in (Greif-Hewitt75, Greif 75). 
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the states at the time A or B are returned, but the state of the cell may be changed by the 
updating messages subsequently arriving before A or B are returned. 

In order to eliminate this impreciseness in the above event specifications, the 
following two points should be made clear. First, states of a cell expressed by the 
conceptual representations must be interpreted strictly in terms of equivalence classes of 
histories of incoming messages. They should not be interpreted to express the current 
contents of the cell. The second point, which logically follows from the first one, is that in 
order to be consistent with the definition of the states expressed by the conceptual 
representations, the state of the cell must change instantaneously when an (update:...) 
message arrives. , 

In general, in specifying behaviors of actors in parallel computations through their 


State changes, the fact that states change instantaneously must be taken into account. 


6.2.2 <Next-cond:..> Clauses 


To express the instantaneous state changes in specifications, we introduce a new 
Specification language construct, <next-cond:..> Clauses. This is usually used in event. 


specifications of the following form. 


<event: [T <e= M] 
<pre-cond: ise > 
<next-cond: ... “assertion... > 
<caused-event: E >> 


This means: when an event [T <== MJ takes places, if the preconditions are satisfied, the 


<assertion>s in the <next-cond: ..> clause hold immediately after the event [T <e= MJ) and 


continue to hold at least until one of the actors appearing in the <assertion>s receives the 
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next message. For example, if the <assertionys mention T or M, they continue to hold at least 
until T or M receives its next message. The assertions in the <next-cond:..> clause can be 
viewed as the preconditions for the next event. A <next-cond:.. clause differs from a 
<post-cond:. .» clause in that assertions in the <post-cond:..>- clause hold at the time the 
corresponding caused event take place, but may not hold before the caused event. When a 
<next-cond:..> clause is used in specifying serial computations, its meaning is identical to 
that for a <post-cond:..> clause. The event E in the <coused-event:...) clause must take place 
eventually. It is often the case that concuirrent events are caused by [T <es MJ.. In such a 
case, we use clauses of the f orm <caused-events: {-<even.p. Other interpretation rules for 
event specif ications, such as those for absent clauses, abbreviated forms and scope rules for 
symbols in clauses are the same as for serial computations. (CE. Sections 43.1 and 43.3, 
Chapter 4) | ; | | 


Using this new construct, a specification of the behavior of a cell in parallel 


Fig. 6.1. A Specification of a Cell 


<event; Ccreate-cell & A] 


<return: C® > . 
<poat-cond: (C is-a (CELL (contents: Aj) >> 


<event: [C <a (contents:)] 
<pre-cond: (C is-a (CELL (contents: A))) > 
. <next-cond: (C is-a (CELL (contents: A))) > 
<return: A >> 


<event: [C <= (update: B)] 
<pre-cond: (C is-a (CELL (contents: A))) > 
<next-cond:..(C tow: ACELL {eontents: B))) > 
| Sreturn: B » 
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computations is written as depicted in Figure 6.1. <Return:..> clauses are used as an 
abbreviated form of a <ecaused-event:..> clause. When a cell actor is created by the 
create-cell actor receiving the initial contents, we need not use a <next-cond:...> Clause in 
expressing the state of the newly created cell, because before the new cell is released nothing 
can happen to change the state of the cell. It should be peinted. out that the equivalence 
relation defining the states:of a cell (which are expressed by conceptual representations) is 
expressed incrementally by the <pre-cond:..> and: <next-cond:...> clauses in the specification in 
Figure 6.1. 


6.3 Examples of Specifications 


In this section, we will discuss three specif ications as examples. The first example 
is a specification of a simple air line reservation system. This example illustrates how the 
behavior of systems which process requests on a first-come-first-served basis is specified by 
our technique. In the second example la specification of semaphores), we will see how 
processes which have requested some actor for resource usages that. have not yet been 
granted are dealt with in expressing the state of the actor. The third example is a 
completely external [i.e. implementation independent) specification of a bounded buffer 
which requires us to express "non-first-come-first-served” scheduling of. requests. 

As was mentioned before, an actor model of a simple post office is studied in- 
Chapter 8. It is shown that overall task specifications of the post | of fi ice can be derived by 
specifications of the individual behavior and mutual interaction of actors in the model. 
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6.3.1 Modelling an Air Line Reservation System — 


As an example, let us consider an air line reservation system. For the sake of 
simplicity, we assume that only one flight is available in the system. A number of travel 
agencies [parallel processes) try to reserve or cancel seats for the flight concurrently. We 
model! the air-tine reservation system as a-flight actor F which-behaves as follows. The 
flight actor F accepts two kinds of messages, : . . | 

(reserve-a-seat: <pacsenger-neme>) and (eenvel-e~seati <petsenger-name>). 

When F receives (reserve-a-seat:..), if free seats are left, the passenger name is appended to © 
the passenger name list for the flight and the number of free seats is decreased by one, and 
a message (ok-its-reserved:) is returned. Otherwise a message (no-more-seats:) is returned. 
When F receives (cancel-a-seat:...), if the passenger name is found ‘in'the passenger name 
list, a message (ok-its-cancelled:) is returned and the passenger name is deleted from the 
passenger name list and the number of free seats is increased by. one. Otherwise a message 
(the-passenger-name-not-found: ) is returned. “Furthermore request by (reserve-a-seet:. .) and 
(eancel-a-seat:. od are processed on af irst-come-first-served basis e, 2 

To write a formal specification of the air Jine reservation system, we need to 
describe the states of the f light actor. For this purpose, we use the following conceptual 


represen ta tion 


: {tea 


(FLIGHT (seats-free: (n>) (pisséniger-name-tit 


which describes the state of a flight actor. The number of free seats is <m> and {8pnl} is 


I. E. A: Ashcroftli9?S} gave a°fiowchart program Which moitels an air line reservation 
system. In his program, each user (or agency) has its own copy of the request handling 
program and all the copies are connected with a single fork operation. Furthermore, the 
number of users must be fixed. 
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the passenger name list for the flight The formal specification of the air line reservation 
system using this conceptual representation is depicted in Figure 6.2. 
Since the states expressed by conceptual representations in the specification are 
defined as equivalence classes of histories of messages sent to F, the number of free seats 
-and the passenger name list given in the conceptual representations does not necessarily 
correspond to those that are actually stored in the system! From the view point of a 
message arriving at F, the states expressed by conceptual representations in <pre-cond:...> 
clauses are virtual. That is to say, those conceptual representations express the information 
that will be true after all the messages previously arrived at F are processed, although 
currently some of those messages may be being processed or some may even be suspended 
in the request queue. Therefore, only air line reservation systems in which the reserve and 
cancel requests are processed on a f irst-come-first-served basis satisfy the specification in 
Figure 6.2. 
It is easy to specify the behavior of air line reservation systems which deal with 
more than one flight and can add and remove flights. To do so, one may use conceptual 


representations which express the flight information for each flight. For example, 
(RESERV ATION-SYSTEM {...(flight-i: (seats-free: <n>)(passenger-name-list: {§pni})) ...}) 


may suffice. In this case, the reservation system thus specified processes the reserve and 
cancel requests on a flight-wise first-come-first-served basis. This implies that requests for | 
different flights may not be processed on a first-come-first-served basis. The technique to 
specify the flight-wise first-come-first-served processing can be applied in specifying file 
1. If the processing of requests were so fast that each request might be processed before the 


next one arrives, the information expressed in the conceptual representations would 
correspond to what is actually stored in the system. 
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Fig. 6.2. A Specification of an Air Line Reservation System 


<enent: [create-flight <= SJ 
<pre-cond: (S > 0) > 
<return: F® > 
<post-cond: (F is-a (FLIGHT (seats free: S} (pessener-name-list: {})))>> 


<event: [F <= (reserve-a-seat: “wes 
(rase-I: 
<pre-cond: (F is-a (FLICHT (seats-free: 0) (passen ger-name-list: {Epni}))p> 
‘<next-cond: (F is-a (F LIGHT (seats-free: 9) (passenger-name-list: {2pni}))> 
<return: (no-mora-seats:) >) 
(case-2: 
<pre-cond: 
(F is-a (FLIGHT (seats-free: N) ) (passengor-name-tist (tenn) 
(N>0) > 
<next-cond: (F is-a (F L ich T Licata frees Ne 1) (psitea gt wanes {tpel NAME})))> 
<return: (ok-its-reserved:) 9° 


<event: [F <= (cancel-a-seat: NAME] 
tease-}: 
<pre-cond: 
(F is-a (FLIGIIT (seats-free: N) (patsenger-name-lst: {tect} 
(pnt {.. NAME .J)> 
<next-cond: (F is-a (FLIGHT (seats-free: N) reverent name tie {Ipni})))> 
<return: ee eaenne Cement tre »y- 
(case-2: 
<pre-cond: 
(F is-a (FLIGHT (seats-free: N) (passenger-name-list: {§Jpnil NAME !pni2})))> 
<next-cond:  is-a (FLIGHT (seais-free: N + 1) eee sae {tpnit Epni2})))> 
<reiurn: (ok-ita-cancelled:). > ):>: a 
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systems, large data base systems, and disk-head scheduling systems [Hoare?74] as long as 


individual files and disk tracks are used on a first-come-first-served basis. 


6.3.2 A Specification of Semaphores 


The behavior of semaphores can be easily specified by our techniques. The state 


of a semaphore is described by conceptual representations of the following form. 
(SEMAPHIORE (counter: <n>) (waiting-q: [$q))) 


where <n> is the number of processes that can still enter the critical section it guards and 
[!q] is the queue of processes waiting to enter the critical section. A specification of a 
semaphore is depicted in Figure 63. 

A message sent to a semaphore consists of a request lie. either P-operation or 
V-operation], and a continuation actor which will be activated when the request to the 
semaphore is granted. The continuation can be viewed as a process that will be awakened. 
As stated in the Case-2 of the second event specification [for P-operation)], when the counter 
is Zero, no message is sent to the continuation. Hence the <caused-event:...> clause has no 
events. In the Case-I! of the third event specification [for V-operation], two events, 


[LC <= (go-ahead:)] and [first <= (go-ahead:)]] are caused concurrently. 
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Fig. 6.3. A Specification of Semaphores 


<event: [ create-semaphore <= NJ . 
<pre-cond: (N20) > 
<return: $* > 
<post-cond:. (S isa (SEMAPHORE (counter: N) (waiting-q: []})).>> . 


erent: [s <== [request: (P-op:), reply-to: C]] 
(Case-}: aa 
. <pre-cond: 
(S is-a (SEMAPHORE (counter: N) (waiting-9: ()))) 
(N>0) > 
<next-cond: (S isa (SEMAPHORE (counter: N= 1) (esiting-« £)))) > 
<caused-event: [C <= ee J de 
(Case-2: ; 
<pre-cond: (S is-a (SEMAPIIORE {countor: 0). (weiting-¢: [tq])).> 
<next-cond: (S is-a (SEMAPHORE (counter: 0) waiting-¢: i] cy) > 


<cansed-events: {}> )»> 


<event: [S <e= leegutete Wate) reply-to: c]} 

(Case-!: 
<pre-cond:. (S is-a (SEMAPHORE (counter: 0) (waiting-g: [fizet irest}))) > 
<next-cond: (S is-a (SEMAPHORE (counter: 0) (woiting-q: {trest)))) > 
Ceaused-evente: {IC (go-ahead J, ines tse-abesey] py 

(Case-2: 
<pre-cond: (S is-a (SEMAPHORE canna N) (waitin g-¢: m» 
<next-cond: (S is-a (SEMAPHORE (counter: N +1) Sere Om > 
<caused-event: [C <= (ge-aheed:)} > > 
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6.3.3 A Specification of a Bounded Buffer 


As a simple example of specifications for actors which do scheduling of incoming 
requests, we specify a desirable behavior of a character buffer of a fixed size N with which 
concurrent processes communicate to one another. 

A buffer actor B accepts two kinds of requests, (remove:) and (append: <character>), 
and it can hold at most N characters. Characters are appended or removed from the 
buffer on a first-in-first-out basis. But requests are mot necessarily granted on a 
" first-come-first-served basis, because a character should be appended only when the buffer 
is not full and it should be removed only when the buffer is not empty. This implies that 
when the buffer is empty, (remove:) requests must be suspended until the buffer becomes 
non-empty by an (append:..) request arriving later. Similarly, when the buffer is full, 
(appends) requests must be suspended until the buffer becomes non-full. Therefore, in 
determining external states of the buffer, we must take into account such suspended 
requests (waiting processes). 

To express the states of the buffer, we use conceptual representations of the 


following form. 
(BOUNDED-BUFFER (q,: [.-q,: (...) (string: [--)) 


Tq and q, denote queues of suspended messages for (append:...) and (remove:) requests, 
respectively. String denotes the string storage used as a buffer. [Remember that the states 
expressed by the conceptual representations are defined in terms of the equivalence classes 
of the past message histories. So q,, q, and string do not necessarily correspond to the 
queues of requests which are actually suspended or the string of characters which are 
actually stored.) 


In figures 6.4 and 6.5, we give a specification for the behavior of this bounded 
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buffer. The first event specification in Figure 64 describes how the buffer is created. 
Note that the two queues q, and ¢, as well. as the string: storage are empty when the buffer 
is created. 

The second event specification in Figure 6.4 describes the behavior of the buffer 
in response to a message M for a (remewe:} request. Note that the message: M explicitly 
contains a continuation C. There are three cases depending upon the state of the buffer B 
at the time when the message M arrives. Case~1 is the one in which the string storage is 


empty, and no messages for (append:..) requests are suspended iie., Iq = cB, and messages 


Fig. 6.4. A Specification of a Bounded Buffer of Site N (Creation and. Removing a 
Character) 


<event: [ create-bountied-butfer << re 
Sreturn: B* . 
<post-cond: (B is-e (BOUNDED-BUFFER (qq: (Mae OMetring: ‘D> » 


<event: [B <= MJ] 
where M= Lpogeent: (remove: ) reply at: Cc} 
(Case-I: 
<pre-cond: (B is-a (BOUNDED-BUFFER (q,: (ee [Sy] string: [}))) > 
<next-cond: (B is-c (BOUNDED-BUFFER (q,: OMe, Uy M))(string: a») > 
<caused-ewents: {} >) 
(Case-2: 
<pre-cond: (B is-a (BOUNDED-BUFFER (q,: (IMe,2 ()Mstring: [X #8}))) > 
<next-cond: (B is-a (BOUNDED-BUFFER (q,: (Mg, ODiGrring: [fs}))) > 
<caused-event: Cc. = + Gemened: xy >) 
(Case-3: 
<pre-cond: 
(B is-a (BOUNDED-BUF F RR Ue! [MM bMay [Matring: x is)))) 
(length({X 38}) = N) 
(MM = [request: (append: XX) reply-to: CC]) > 
<next-cond: (B is-a (BOUNDED-BUF FER Ge. [DG []Mstring: [$8 XX}))) > 
<caused-eventa: {C <= (removed: XJ], [CC <= (append-done:)}} >) > 
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for (remove:) requests may or may not be suspended, lie, q, = (ty?! }. In this case, the 
message M is enqueued at the end of q, and no events are caused. When the string storage 
is not empty and both q, and Gq, are empty (Case-2), the first character X in the string 
storage is deleted and sent back to the continuation C as a reply message (removed: X). 
Case-3 is the one in which the string storage is full [i.e length([X #s]) = NJ, at least one 
message for an (append:...) request is suspended lie, q, = [MM &x] ] and no messages for 
(remove:) requests are suspended. In this case, the following change in the state of B 
happens: the first element MM in = qa, | which is of the form 
[request: (append: XX) reply-to: CC}, is deleted from the queue, the character XX is added at . 
the end of the string storage, and the first character X in the string storage is deleted. 
Then, two events are caused concurrently: [C <= (removed: X)]} where X is sent to the 
continuation C and [[CC <= (append-done:)]] where the acknowledging message for the 
message MM for an (append:..) request is sent to the continuation CC. (Cf. the remarks 
below.) 

The behavior of the buffer in response to messages for (append :...) requests is 
described by the event specifications given in Figure 6.5. This event specification and the 
one for (remove:) requests in Figure 6.4 are symmetrical: By exchanging the roles of q, and 
q, and the conditions expressing the upper bound and lower bound of the length of the 
buffer, one is obtained from the other. 

It should be pointed out that the six cases for the state of the buffer considered in 
the event specifications in Figure 6.4 and 6.5 are mutually exclusive and enumerate all cases 


of the states which the buffer can be in if it is created with q,, q,, and the string storage 


1. Recall that [fy] can be an empty conceptual sequence. Cf. Sections 2.2.3 and 2.3.5, in 
Chapter 2. 
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empty. One should be reminded that the states of the buffer are defined in terms of 
equivalence classes of past histories of messages sent {o it, and, that the. state changes 
described in the specif ication are instantaneous as they are expressed by assertions in the 
<next-cond:.. clauses. Thus, g, can be nan-empty only if. string is empty and ¢, can be 


non-empty only if string is full, and consequently, 9g, and q, cannot be non-empty at the 


same time. 


From the specification given in. Figures 6.4 and 65, it is easy to observe the 


Fig. 6.5. A Specification of a Bounded Buffer (Appending a Character) 


<erent: [B <= MJ 
whore M ® [request: (append: X) reply-te: C] 
(Case-I: 
_ <pre-cond: 
-(B is-a (BOUNDED-BUF FER (q,: (ix)(q,: (JXatring: [18}))) 
(length([8s]) = N) > 
<next-cond: (B is-a (BOUNDED-BUF FER (q,: Ux May: [])(string: [28}))) > 
<cauaed-events: {} >) 
(Case-2: 
. <pre-cond: 
(B isa (ROUNDED-BUFFER (es MG, (strings [en 
(length([Es}) <.N) > rae ae ty 
<next-cond: (B is-a (BOUNDED-BUF F ER Gag: Wee O)tstring: [ts xp; > 
<caused-event: [C <= (append-done: MD ay 
(Case-3: 
<pre-cond: 
(B is-a (BOUNDED-BUFFER lag! (Mae (wa by ))itring: oo 
(MM = [requests (ramove:) reply-to: OC} ™: : 
<next-cond: (B is-a (BOUNDED-BUF FER (q,: [])q,5 [fy] Mstring: []))) > 
<caused-events: {[C <= (append-done:)], [CC <= (removed: X)J} >) > 
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following property of the bounded buffer: It is always the case that the character removed 
in response to the n-th (remove:) request is the one which was appended by the n-th 
(append:...) request. More formally, 
Property (First-In-First-Out) 
Let EI = [[B <== [request: (remove:), reply-to: co 
denote the i-th event where B receives a (remove:) request, and 
E4 = [[B <== (request: (append: X jr reply-to: ?]] 


denote the j-th event where B receives an (append:...) request. 
For any n > 0, if both Ef and E@ exist, 


then there exist an event E =[[C,, <== [reply: (removed: X,))]]_ such that EF -act-> E. 


6.4 Behavioral Equations 


As noted in the beginning of the previous section, our specification method is 


roughly summarized asi! 


"Given a state of an actor A, the behavior of A in response to a message M is 
expressed by the new state of A and the finite concurrent events caused by the 
event [[A <== MJ.” 
The method suggests to us that a state of A can be viewed as a certain mathematical 
function F~ whose domain is a set M of actors (or messages) and whose range is a direct 
product of a set Sa, of states of A and a finite power set P(T x M1) of a direct product 


of a set T of target actors and M. [Note that T x M corresponds to a set of events.] 


Fa: M ----> S,xP(T xM). 


l. For the sake of simplicity, we do not take into account the states of the message M and 
the actors involving in the caused events. — 
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Whether or not the function Fa exists as a well defined mathematical object needs 
to be proved, but we do believe that the following isomorphism would be shown to hold by 
a certain domain construction for § A Similar to that for the lambda calculus done by D. 


Scott[1972]. 
Sp = (M aeee) S,xP(TxM)). 


where ( ----> —) denotes a set of continuous functions with a specified domain and range. 
The construction of such domains will establish the mathematical meanings of actor states 
which are described by conceptual representations. 

The above isomorphism is inspired by the notion of processes proposed by R. 
Milner [Milner73]. Extending the work of D. Scott, R. Milner has expressed the meaning 
of a program by the notion of processes. He defines his notion of processes by the 


following isomorphism. 
PZ CV ---- P xV) 


which says that a set P of processes is isomorphic to a set of continuous functions from a 
domain V of values to a direct product of P and V. There are fundamental differences 
between his approach and ours, due to the framework of the two approaches. Our 
approach is based on the computation model in which a computation is defined as a 
partially ordered set of events and for each actor, a total order {called an arrival ordering) 
is defined. In Milner’s approach, a computation is defined as a composition of processes in 
which parallelism is expressed as a non-deterministic choice of processes by “oracles”. The | 
introduction of oracles forces us to consider uninteresting details of the interleaving of 
concurrent processes. Furthermore, the lack of arrival ordering makes it difficult to deal 
with the issues of fairness and starvation. 


C. Hewitt and H. Baker [Hewitt-Baker77] have shown that the behavior of a pure 
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actor can be defined as the minimal fixpoint of a continuous functional. This result does 
not apply to the whole set of actors. Thus we hope that the approach exemplified by the 


above isomorphism will be able to deal with the whole class of determinate actors. 
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7. Verifying Parallel Computations 


In this chapter, our techniques for verification of actors which are used in parallel 
computations (in multi-process environments) are presented. In the first section, a special 
class of actors which are used for synchronization and scheduling of requests is described. 
To illustrate the verification techniques, an air line reservation system and a bounded 
buffer which are implemented with such a class of actors are considered in the subsequent 


sections. 


- 149 - 


7.1 Introduction 


As noted earlier, if, in a parallel computation, concurrent processes do not interact 
with each other, the parallel computation can be viewed as a collection of mutually 
independent serial computations and its specification is given as the collection of 
specifications for the serial computations. The verification of such a parallel computation 
is. nothing but a repetition of the verifications. of serial computations. Consequently no 
special techniques in addition to those for serial computations are required. 

In the previous chapter, we have developed Specification methods which are 
applied to computations in which interactions among concurrent processes are involved. 
Since interactions between processes are performed by sending messages to certain kinds of 
actors, our Specification methods focus upon the behaviors of such actors. We have given 
various specifications for such actors. But those specifications merely express the behavior 
that users or implementors of such actors assume or hope they have. There is no guarantee 
that actually implemented actors behave correctly with respect to their specifications. 

In this chapter, we first discuss how such actors are implemented and then explain 
how they are verified. As examples, we will verify implementations of an air line 


reservation system and a bounded buffer.: 


7.2 Serializers 


In our model of computation, we use a special class of actors, called 
serializers[Atkinson-Hewitt77], to realize synchronization _and scheduling of message 
transmissions in a uniform and modular fashion. In this section we explain the concept of 


serializers and give precise specifications for their behavior. The language constructs for 


- 1- 
serializers, and their relationship to other synchronization primitives such as monitors 


[Brinch-Hansen73, Hoare74], are discussed in [Atkinson-Hewitt77]. 


7.2.1 Concept of Serializers 


The purpose of a serializer is to enforce orderly uses of resource-like actors [such 
as I/O devices, message buffers, directories, files, data base systems: etc} by concurrently 
running processes: Some resources must be. used. one.at.a time to guarantee correct, 
functioning of hardware, some should be used on a certain priority basis for special 
demands and efficiency reasons, and some should receive messages in a proper order for 
maintaining their integrity. 

In order to control access to a resource, we encase the resource in a serializer to 
intercept the messages sent to it. Any processes which need to use the resource can send a 
request message to it freely, but all requests are first. received bythe serializer. The 
Serializer sends the requests to the resource. at an appropriste time depending upon the 
physical requirements. of the resource and the. scheduling and priority. adopted for the 
resource. No request message arrives at the the. resource directly. We call: the arrival ef 
such a request message at the serializer, a serializer request-and:the arrival at the resource 
of a request message which is sent by the serializer, a resource request. 

In order for a serializer to properly perform such synchronization and scheduling 
of requests, it must know various information such as what state the resource isin, which — 
requests are being suspended, and which are being granted. To keep such information 
accurate, the reply (or results) produced upon the completion of the use of the resource is 
first sent to the serializer, and some of the information kept in the serializer is updated, and 


then the serializer returns the reply as a response for the original serializer request. We call 
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the former event a resource reply and the latter @ serializer reply. | 


LLLLAL ALI L fEE 


serializer request 


serializer reply 


| 


Thus a typical sequence of events associated with the use of the resource encased 
by a serializer starts with a serializer request and then the resource request is made when it 
is appropriate. The resource reply follows upon the completion of the use of the resource, 
and finally the serializer reply takes place as a response to the original Serializer request. 


The diagram above shows this sequence of events. 


7.2.2 Behavior of Serializers 


As was mentioned above, a serializer maintains certain kinds of information to 
make resource requests take place in such a way that desirable resource usage is. 
accomplished. To store and update such information, a serialzer may have three types of 
information storage: queues, crowds and counters. ‘Below we look into the behavior of a 
serializer in more detail by explaining the functions of such information storage. 


Queues in a serializer are used to store request messages. which have arrived at the 
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serializer, but whose corresponding resource. requests have not yet taken place. They also 
record the order of the arrivals of such request messages. A serializer may have more than 
one queue to sort out-request messages by thelr types. (For example, requests for reading 
data are stored in a queue different from the one for ‘write requests.) Suppose that a 
message [request: RQ. réply-te: C} arrives. at-a. serializer 6. (This is a serializer request 
event.) If the request RQ should not be sent to the resource encased by G at that time, the 
message [requeat: RQ reply-to: C} is put at the Year of. a queue in G. Later on, when the 
message is at the. front of the queue and certain, conditions for synchronization or ~ 
scheduling are met, the message is removed~ from: the queue and a new message 
[request: RQ reply-to: BP) is created and sent to the resource. This is a resource request | 
event. RQ is the request contained in the original message sent to G. BP is a newly created 
actor, called a buck passer, which has the fovowine. special properties: 

(1) BP remembers (knows about) the serializer G by which it is created. 

(2) BP remembers the continuation! c contained in the original message sent to G. 

(3) BP shares the same arrival ordering with the serializer G. 2 
The third property means that the order between the arrival of a ‘mewage at G and the 
arrival of a message at BP is always defined. {More intuitively, BP and G share the same 
arbiter.) Since BP is sent to the resource as the continuation in the message for the resource 
request, BP eventually receives a reply from the resource, if the resource replies. This is a 
resource reply event. Although we explained in the previous subsection that the reply from 


the resource is sent to the crlalizes G, the above account: is more > accurate. However, the © 


I. See Sections 3.1.2 and 3.1.3. in chapee 3 for the def inition, of continuation. 

2. The model of computation defined in Chapter 3 “does not assume this kind of 
“combined” arrival ordering. _This assumption is solely-for the: simplicity of. explanation. 
By letting the buck passer BP send itself to the serializer G together with the message it 
received, this assumption can be eliminated: See appendix V: 
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previous explanation is justified by the property of the buck passer BP which shares the 
same arrival ordering with the serializer G. 

Crowds in a serializer are used to store buck passers which are created when 
requests are sent to the resource by the Serializer. The existence of some buck passer BP in 
a crowd indicates that the corresponding use of the resource has not been completed yet, 
because BP is taken out from the crowd only when BP receives the reply from the resource 
(which means the completion of the resource usage). [It is the third property of a buck 
passer described above that allows the serializer to eliminate the buck passer from the 
crowd upon the arrival of the reply at the buck passer.) More than one crowd may be used 
in a serializer to distinguish the types of resource requests being granted. For example, by 
having two crowds, a serializer encasing some file is able to know whether the file is 
currently being read or written. 

Let us consider the behavior of a serializer:'in a resource reply event. Suppose that 
a buck passer BP in a crowd CR receives a reply RP from the resource. If certain 
synchronization and scheduling conditions are met, the serializer takes out the front element 
(request: RQ reply-to: C] from one of the queues, and a new request message of the form 
[request: RQ reply-to: NBP] is created and sent to the resource. When the new request 
message is created, a new buck passer NBP (which remembers C) is created and put in a 
crowd (which may be different from the crowd CR). At the same time, the old buck passer 
BP is deleted from CR. The serializer has another responsibility. It must send the reply RP 
(just received by the buck passer BP) to the continuation remembered by BP. This is the 
Serializer reply event. Recall that BP is created for remembering the continuation originally 
contained in the message sent to the Serializer. 

Counters in a serializer are used to record various numbers about events associated 


with the serializer. For example, a counter records the difference between the numbers of 
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resource reply events of Various kinds. A simple example of ne, uses of a counter will be 


found in Section 7.4. 


7.2.3 One-at-at-Time § Serializer (An Example) 


The behavior of serializess informally sapheineds da the previous subsections can be 
rigorously specified in our formalism. Te illustrate how their. behavior.is expressed in our . 
formalism, we give a formal specification of a simple serializer: called -one-at-a:time in 
Figure 7.1. A resource encased by this serializer is used, at most, by-one process at a time, 
and on a first-come-f irst-served basis, ; . ss | 

The first event - specification. in. Figure. 14 says. that when an actor 
create-one-at-a-time receives a resource R, it creates a serializer G-which has:one queue and 
one crowd, both of ‘which are initially empty, ie 

. The behavior of G in response to.a request message ‘dels on the state-of G. If 
both the queue and crowd are empty. [(Gese-J:).0f the.secand event.specification in Figure 
7.1], a buck. passer BP is created and put in-the.crowd and..a- request message containing BP 
as the continuation is sent to the resource R. Otherwise (Gase-3:)the request message .is 7 
enqueued and no. event is caused, 

_ The third event specification says-that when. a: ore passer BP which is inside the. 
crowd of G receives a reply message, if the. queye of. G. is empty-(Cese-I:),! BP is deleted 
L. Being able to check whether or not the queue of c is empty telies CH ‘the assumption that 
the state of G caa be determined at the time when the bac: pryabd reveives a message. 
This assumption is implied by one of the general properties of buck buck passers that a buck | 
passer shares the arrival ordering with the serializer’b y which’ it is created. In Appendix 


V, a specification. of. one-at-a-time serializers..whigh. does- nat-rely.on- this. assumption is 
given. 


= BB =*, 
Fig. 7.1. A Specification of a One-at-a-Time Scheduler 


<erent: [ create-one-at-a-time <= RJ 
<return: G* > 
ac (G is-a (ONE-AT-A-TIME (queue: (]crowd: Mresouree: R))) >» 


<erient: [G <s= MJ ; 
where M= [request: RQ reply-to: C} 
(Case-]: 
<pre-cond: (G is-a (ONE-AT-A-TIME (queue: [])(crowd: {})(resource: R))) > 
<next-cond: 
(G is-a (ONE-AT-A-TIME (queue: (]M crowd: {BP*})(resource: R))) 
(BP is-a (BUCK-PASSER (continuation: C)(serializer: G))) > 
<caused-event: [R <== [request: RQ reply-to: BP] >) 
(Case-2: 
<pre-cond: (G is-a (ONE-AT-A-TIME (queue: [1x])(crowd: {BP})(resource: R))) > 
<next-cond: (G is-a (ONE-AT-A-TIME ota [ix M]cresod: {BP} resource: R))) > 
<caused-events: {} >) 


<erent: [LBP <== [reply: AJ] 
uhere (BP is-a (BUCK-PASSER (continuation: C)(serializer: G)))) > 
(Case-1: 
<pre-cond: (G is-a (QNE-AT-A-TIME (quexe: []Mcrotd: {8P} Xresource: R))) > 
<next-cond: (G is-a (ONE-AT-A-TIME (queue: (])(crowd: {})resource: R))) > 
<caused-envent: [C <s= [reply: A] >) 
(Case-2 
<pre- ceond: 
(G is-a (ONE-AT-A-TIME (queue: (WM tx)Merowd: {BPH (resoarce: R))) 
(WM = [request: RQ reply-to: CC}) > 
<next-cond: 
(G is-a (ONE-AT-A-TIME (queue: [#x] (crowd: (NEP*) (resource: RY) 
(NBP is-a (BUCK-PASSER (continuation: CC)(serialixer: G)))> 
<caused-events: { [C <ex [reply: A]g , [LR <am (request: RQ reply-to: NBP]J } >)> 
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from the crowd and the reply message is sent:back to the continuation'C remembered by &P. 
If the queue is not empty (Case-2:), the front element WM which is a suspended request 
message sent to G before is Gequeued and a newly created buck paseer NBP replaces BP in 
the crowd. Thena serializer reply event [c (ez lresl: ‘all and a resource dp ates event 


ILR <== [request: RQ reply-to: NBP]] take place concurrently. 


Before ending this section, we should: méntion : several properties of the 
one-at-a-time serializer which are easily derived from the specification given in Figure 7.1. 

If a resource R is encased by a one-at-a-time serializer before R becomes known to 
other actors, there is no way to access the resource ‘directly! In order to access the resource, 
first a request must be sent to the one-at-a-time serializer. This property holds for any kind 
of serializer (not just for one-at-a-time serializers). We call this property the resource 


confinement of serializers. More formally, 


Property (Resource Confinement of Serializers) 


Let a = [create-a-resource <ax [requaat: I reply-to: sreate~s-sorisiizer)] and 
= [ create-a-serializer <= [request: R reply-te: fot i such that” Fo wact-> Ey, 
where I is used for the creation of a new resource R. 

and let G be a serializer created by Ey. 

If there exists no event EE.= [A <== [request: R reply-co: TJ] 
such that Ep ---> EE ---> Ey, 
then for any event ER = [R <== [request: RQ reply-to: ry]. ; 
there always exists atr event E = EG tox [regaest RQ reply-to: ia) | 
Such that” E: vact"> ER. 


We need to give the definition of an assertion (A is-used-serially) to state the 


properties of one-at-a-time serializers. If the assertion (A is-used-serially) holds, an actor A 


1. We assume that the creator of R does not release any information which makes it 
possible to have access to R. 
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does not receive any message until the current invocation of A is completed. Consequently, 


if the invocation is not completed, no more messages arrive at A. More formally, 


Definition (A is-used-serially) 
If there exists an event Ej = [LA <== [request: RQ; reply-to: CJ]. 
then 


if there exists another event E ie LA <== [request: RQ; reply-to: CI] 
such that i# j and Ej -arr->, E}. 
then there must exist EE, = [C; <== [reply: ?]] 
such that E ; ---> EE; ---> Ej 


Property-I (Serial Use of Resource) 
If an resource actor R encased by a one-at-a-time serializer, then (R is-used-serially) holds. 


This property is derived from the fact that the number of buck passer actors in the crowd 


of the serializer is always one at most. 


Definition (A is-guaranteed-to-reply) 
For an event E = [LA <== [request: RQ reply-to: C]], 
there always exists an event EE = [[C <e= [reply: ?7)] such that E -act-> EE. 


Property-II (Guaranteed Resource Access) 


Suppose that the resource actor R encased by a one-at-a-time serializer G satisfies 
the following condition: if (R is-used-serially), then (R is-guaranteed-to-reply). 
Then, for any event E = [G <== [request: RQ reply-to: ?]]], 
there always exists an event ER = [[R <== [request: RQ reply-to: ?]]] such that E -act-> ER. 


This property is derived from Property-I by induction on the number of messages that — 


have already arrived at G. 
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Property-II] (First Come First Resource Access) 
Under the same premise given in Property-I]I, 
for any Ej, Ej where EF; = [. G <== [request: RQ, reply-to: C.J], k = i, j, 
if E, ->q E; 


then ER; ara! Ej 


where ER, = (LR <== [request: RQ, reply-to: ?)]], k = i, j. 


This property is derived from the fact that requests sent to G are recorded in the queue of 


which preserves the order of arrival. 
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7.3 Verifying Implementations of Actors | 


In this section, we discuss our techniques for the following class of verification 


problems. 


"Given an actor A which shows some behavior in serial computations (i.e., when it 
is used serially). Suppose that an actor B is implemented as a one-at-a-time 
serializer encasing the actor A. Then we would like to verify that even if B is sent 
messages concurrently, B shows the same behavior as A does in serial computations.” 


This problem is not trivial because the states of A and B which are used to describe their 
behavior in specifications are expressed by different conceptual representations. The 
essential part of the verification is the use of the mapping (implementation invariant) 
between two different conceptual representations. The technique illustrated below is an 
extension of the one used for the verification of actors behaving as information storage’ 
discussed in Section 5.3, Chapter 5. The verification of implementations using more 
complicated serializers is discussed in the next section (7.4). 

In what follows, as an example of such verification problems, we will demonstrate 
that the implementation of an air line reservation system given below meets its specification 


depicted in Figure 7.2 (which is the same one given in Figure 6.2 in Chapter 6). 


7.3.1 An Implementation of an Air Line Reservation System 


We implement an air line reservation system which is supposed to meet the 
specification in Figure 7.2 in two steps. First, we implement a flight data actor which 
satisfies the specif ication in Figure 7.2 as long as it is used serially. Then it is encased by a 
one-at-a-time serializer. [The flight data actor corresponds to the actor A in the above 
problem statement.] 


The code given in Figure 7.3 is an implementation of such a flight data actor. It 
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Fig. 7.2. A Specification of an Air Line Reservation System 


<event: [create-flight <= SJ 
<pre-cond: (§ > 0}> 
«return: F* > 
<post-cond: (F is-a (FLIGHT (scats-free: $) pre e ae 


<erent: [[F <= (reserve-a-seat: NAME)}. 
(case-I: 
<pre-cond: (F is-a (F LIGHT (soate-free: Q). Llane ordi let {Epni})))> 
‘<next-cond: (F isa (FLIGHT (seats-free: 0) (passenger-name-list: {Epni})))> 
<return: (no-more-seati:) >) 
{ease-2: 
<pre-cond: 
(F is-a (FLICHT (seats-free: N) ipatienae seme {toon 
(N>0) > 
<next-cond: (F is-a (FLIGHT (seate-free: N = 1) (peseengor-neme-lis {Ipnl NAME})))> 
<return: (ok-its-reserved:) >) 


<event: [F <= tcancel-e-soatt NAME)]} 
(ease-I: 
<pre-cond: 
(F is-a (FLIGUT (seats- free: N) (passenger-name-list: {Lpni}))) 
(pni # {... NAME ...})> 
<next-cond: (F ts-a (FLIGHT (scats-free: NY (pessenger-name-list: {1pni}))> 
<return: (the-passenger-name-noi-feund:) >) 
(rase-2: : 
<pre-cond: 
(F is-a (FLIGHT (seats-free: N) (sanisiite names aa NAME §pni2})))> 
<next-cand: (E-is-o (FLIGHT (seate-froe: + 1). panies nema tia {ipnli tpni2})))> 
<return: (ok-its-cancelled:) > )> 
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Fig. 7.3. A Code For a Flight Data 


(create-flight-data =s) = 


(let (seats-free initially s) ja variable seats-free is initialized to s. 
(passenger-name-list initially (create-empty-set)) 
then 


ja variable passenger- is initialized to an empty sect. 
(cases 


(=> (reserve-a-seat: =name) 


jwhen a (reserve-...) message is received, 
(rules (seats-free = 0) 


sif the value of seats-free is O 


(=> yes (no-more-seats:)) jthen a (no-more-seats:) is returned. 


(=> no 
(seats-free © (seats-free = 1)) 
(add name to passenger-name-list) 
(ok-its-reserved:)))) 
(=> (cancel-a-seat: =name) 


jotherwise 

sthe value of seats-free is decreased by one 
jname is added to the list. 

ja message (ok-its-reserved:) is returned. 
jwhen a (cancel-...) message is received, 


(rules (name in passenger-name-list) stf name is found in the passenger name list, 


(=> yes jthen 


jname is deleted from the list 
jthe value of seats-free is increased by one 
j(ok-its-cancelled:) is returned. 

=> no (the-passenger-name-not-found:)) )) )) ;otherwise (the-passenger-...) is returned. 


(delete name from passenger-name-list) 
(seats-free © (seats-free + 1)) 
(ok-its-cancelled:)) 


should be noted that if the flight data actor were sent more than one message concurrently, 
anomalous results would be caused. For example, if (reserve-a-seat:...) and (cancel-a-seat:...) 
message are sent concurrently, (no-more-seats:) message might be returned even if there are 
still vacant seats. Therefore this actor must be used serially. . 

We give a specification of this actor in Figure 7.4. Though this specification looks 
Similar to that for the air line reservation system in Figure 7.2, there are important 


diffferences. In this specification conceptual representations of the following form are 


used. 


(FLIGHT-DATA (seats-free: ?)(passenger-name-list: {...})) 
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Fig. 7.4. A Specification of A Flight Data Actor 


<event: [create-flight-data <= S$] 
<pre-cond: (S > 0) > 


<return: FD* > 
<post-cond: (FD is-a (FLIGHT-DATA (soats-free: $) (passener-name-list: {})))>> 


<event: [FD <= (reserve-a-seat: NAME)] 
where (FD is-used-scrially) 
(case-I: 
<pre-cond: (FD is-a (FLIGHT-DATA (scats-free: 0) (passenger-name-list: {§pni})))> 
<return: (no-more-seats:) >) 
<post-cond: (FD is-a (FLIGIT-DATA (seats-free: 0) (passenger-name-list: {4pni})))> ) 
(case-2: 
<pre-cond: 
(FO is-a (FLIGHT-DATA (seats-free: N) (passenger-name-list: {§pnt}))) 
(N>0) > 
<return: (ok-its-reserued:) > 
‘trond: 


(FD is-a (FLIGHT-DATA (seats-free: N = 1) (passenger-name-list: {Ipni NAME})))>)> 


<event: [[FD <= (cancel-a-seat: NAME)] 
tchore (FD is-used-serially) 
(case-1: 
<pre-cond: 
(FD is-a (FLIGHT-DATA (seats-free: N) (passenger-name-list: {8 pni}))) 
(pnt # {... NAME ...})> 
<return: (the-passenger-name-not-found:) > 
<post-cond: (F is-a (FLIGHT-DATA (seats-free: N) (passenger-name-list: {¥pni})))> ) 
(case-2: 
<pre-cond: 
(FD is-a (F LIGIIT-DATA (seats-free: N) (passenger-name-list: {Ipnil NAME Ipni2})))> 
<return: (ok-its-cancelled:) > 
<post-cond: 


(FD is-a (FLIGHT-DATA (seats-free: N + 1) (passenger-name-list: {ipnii Epni2})))>)> 
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Notice that assertions of the form (FD is-used-serially) are given in the where clauses of the 
second and third event specifications. This means that those event specifications are valid 
only if FD is used serially. Furthermore, <post-cond: ..> clauses are used instead of 
<neaxt-cond:..> clauses. This means that assertions in the <post-cond:...> clauses hold at the 
time when the caused events take place. : | 

The following property holds for the flight data actor because all the <event:...> 
clauses have the corresponding <return:..> clauses. This property is used in the verification 


in the next subsection. | 


Property-1V: If (FD is-used-serially), then (FD is-guaranteed-to-reply). 


7.3.2 Verification of the Air Line Reservation System 


The implementation is completed by “encasing the flight data actor by a 
one-at-a-time serializer. That is, the implementation of ‘the ‘treste-flight actor is expressed 
by the following PLASMA code: . 


(createflight =s) = (create-one-at-a-time (create-flight-date s)). 


Below we demonstrate that the above code meets the specification of the air line reservation . 


system shown in Figure 7.2. The symbolic evaluation of the code 
(create-one-at-a-time (create-fiight-data s)) 


reveals the following facts: 
(1) an actor FD is created by [create-flight-date <x s] [from the specification in Figure 
7.4.1, 


(2) a serializer G is created by [create-one-at-a-time <= FD] [from the specification in 
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Figure 7.1.) and 
(3) the two actors satisfy the following assertions immediately after the creation of G. 
| (G is-a (ONE-AT-A-TIME (queue: [])(crowd: {})(resource: FD))) 
(FD is-a (FLIGHT-DATA (scats-free: s)(passenger-name-list: {}))) 
We will establish that G satisfies the specification of the flight actor (air line 
reservation system) given in Figure 7.2. The specification of the flight actor G is written in 


terms of conceptual representations of the form: 
(G is-a (FLIGHT (seats-free: ?)(passenger-name-list: {...}))) (x) 


(Notice that F in the specification is instantiated as G.) On the other hand, G is 
implemented as a one-at-a-time serializer that encases the flight data actor FD, which is 
expressed by the following two assertions: 

(G is-a (ONE-AT-A-TIME (queue: [...] crowd: ‘Divenoarce! FD))) 

(FD is-a (FLIGHT-DATA (seats-free: 2)(passenger-name-list: {...}))) (*) 
This means that we have two views of G: an external view expressed by (*) and an internal 
implementation expressed by (**) above. In order to show that the implementation satisfies 
the specification written in terms of the external view, we must establish a certain relation 
between the two views. Such a relation is similar to implementation invariants used in the 
verification of an actor behaving as information storage (Cf. Section 5.3, Chapter 5). 


The relation we need is: 


"If G satisfies the assertion 
(G is-a (FLIGHT (seats-free: N) (passenger-name-list: {!pni}))) 
in a situation where G receives a message [request: RQ reply-to: 7), 
then FD always satisfies the assertion 
(FD is-a (FLIGHT-DATA (seats-free: N) (passenger-name-list: {Spnl}))) 
in the situation where FD receives a message [request: RQ reply-to: 7]. ” 
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We actually prove the validity of this relation in the next subsection 7.3.3; this relation is 
assumed in the subsequent discussion. The following is the formal statement of the above 


relation. 


<Implementation-invariant: 
if (Gis-a (FLIGHT (seats-free: N) (passenger-name-list: {¥pni}))) in 8 
where & = Sit([ G <s= [request: RQ reply-to: ?J]]) 
then 
(FD is-a (FLIGHT-DATA (scats-free: N) (passenger-name-list: {¥pni}))) in 8S” 
where §’ = Sit( FD <== [request: RQ reply-to: ?]]) >. 


Sit(E) expresses the situation where an event E takes place. The implemenation invariant 
can be viewed as the counterpart of an “invariant” in parallel process environments, which 
was first introduced by C.A.R. Hoare [Hoare 1972] to show correctness of implementations 


of data structures used in serial computations. (See the remarks in Section 5.3.1, Chapter 5.) 


' Now let us demonstrate the verification of the implementation against the 


following event specification given in Figure 7.2. 


<erent: [[F <= (reserve-a-seat: NAME)]] 
(case-I]: 
<pre-cond: (F is-a (FLIGIIT (seats-free: 0) (passenger-name-list: {¥pni})))> 
<next-cond: (F is-a (FLIGIIT (seats-free: 0) (passenger-name-list: {¥pni})))> 
<return: (no-more-seats:) >) , 
(case-2: 
<pre-cond: 
(F is-a (FLIGHT (seats-free: N) (passenger-name-list: {ipni}))) 
(N>0) > 
<next-cond: (F is-a (FLIGHT (seats-free: N = 1) (passenger-name-list: {8pnt NAME})))> 
<return: (ok-its-reserved:) >)> 


There are two cases to be considered. We only consider the (Case-2...) clause. The 
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one-at-a-time serializer G receives a (reserve-a-seat: NAME) request RQ. Since the flight data 
actor FD is guaranteed to reply if it is used serially (trom Property-IV), the specification for 
a one-at-a-time guarantees that the (reserve-a-seat: NAME) request RQ is received by FD (from 
' Property-I]). To know the state of the flight data actor FD at the time of the arrival of RQ, 


the above implementation invariant is used. Since the state of G at the time of the arrival 
of RQ at G is described as: 


aa is-a ie LIGHT (scats-freo: (pausengor-name it (tee) 
the state of FO at the time of the arrival of iM at FD ia described as. 
(FD is-a (FLIGHT-DATA (seats-free: N); (passonger-name-tiss: {ipnl}))). 


Then the (Case-2...) clause in the Ceverit:..> clause of thé specification for flight-data actors 
in Figure 7.4 is referred to. Since the precondition that FD’ mast be used serially is satisfied 
(from Property-}), the (Cese-2...) clause of the specification for flight data actors in Figure 
7.4 tells us that | | 


(l) (ok-its-reserved:) is returned, and 


(2) the state of FD is now expressed as: 
(FD is-a (FLIGHT-DATA (seat-froe: N = 1) (pissenger-name-list: {Ipni NAME}))). 
(1) is what the <retarn;..> clause in the above event spesiiaion requices! 1 To complete the 
demonstration, we must show that the assertion ce 
(G is-a (F LIGH T vee ee! Ne ae eeeelae tee {ped AMEDD: 


aoe 


in the <next-cond:..> clause of the sive event specification holds when G meceives ne next 


1. More precisely, (ok-its-reserved:) is first sent to the serializer G and then G returns it. 
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message RQ’. To do so, again the implementation is used. - It translates the above 
requirement as follows: | 
" (FD is-a (FLIGHT-DATA (scat-free: N ~ 1) (pan ger-name-ist {pnt pa 
holds when FO: receives RQ’. ” 2. 
This is guaranteed by. (2) because FD does not change its state until the next message RQ’ 
arrives at FD. Thus Case-2 is shown. Case-l may ‘be shown analogously. The event 
specification for [G <= (cancel-a-seat: NAME))] is also established analogously. 

The demonstration above assumes that dialed ‘can: ‘have access to the flight data 
actor FD except through the serializer G. This assumption. always. holds. because the flight — 
data actor FO created by CU createntlight-dete <= 8] is sent directly. to the ereate-one-at-a-time 
actor and never released outside the newly created onesatvavtime serializer G. (Cf. the 
PLASMA code in the beginning of this subsection and Property aieae Confinement of 


Serializers).) 


7.3.3 Establishing the Implementation Invariant 


The verification in the previous subsection relies critically on the use of the 
following implementation invariant. In this subsection we will establish ‘the validity of this 
implementation invariant. 


<i mplementation-invariant: 
if (G is-a (FLIGHT (scats-free: N) (passengor-name-list: {Upni}))) in =} 
where & = Sit(LG <e= (request: RQ roply-to: Oe 
then 
(FD is-e (FLIGHT-DATA. Ciseie head N) (aihiew ase {4pni}))) in 8” 
where §° = Stel FD ee (requests. RQ reply-te: m >. 


(Proof) The proof is done by induction on ‘the number M of messages » which have already 
arrived at G. ; ngs ay ofS 
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<Induction Base> 
M =0: Since no message has arrived before, when the first message 
[request: RQ reply-to: C] arrives at G, G is in the same state as it was in at the time of its 
creation. So the state of G is expressed as 
(G iswe (FLAGILT. (reate-free:'S)passenger-nametist: {}))).. 
Since G is created as a one-at-a-time serializer and its queue and crowd. are initially empty, 
the state of G is also expressed as 
(G is-a-(SERIABIZER (queue: [])terowd: (]iresource: FD))) and 


(FD is-a (ELIGHT-DAPN (neats-feee: Shpassenger-name-lis: {}))) 
Then from the "guaranteed resource access” property of G (Property-Il), the following event 
is caused. 

[FD.<e= [request::RQ reply-to: ?)} : - : 

When this event occurs, FD is still in the same state as it was in at the time of its creation 
because “resource confinement” property of serializers is Satisfied. ‘So the state of the FD is 
expressed as 

(FD is-a: (F. L ICH T-DATA (seats-free: Slpesengor-heme-ist £$3))) 
Hence the induction base is proved. — 


<Induction Hypothesis> 
M =k: We assume that the following relation holds. 
if (G is-a (FLIGHT (seats-free: N) (passenger-name-list: {Ipni}))) holds 
in Sit([G <== (request: RQ, reply-to: 7)]) 
then (FD is-a (FLIGHT-DATA (seats-free: N) ge delaras {Epni}))) holds 
in Sit{[ FD <e= [request: RQ, reply-to: TR 


<Induction Step> 
M =k+ I: Let us assume that the antecedent of the Induction Hypothesis halds. Then we 


Case-l: RQ, = (reserve-a-seat: NAME), and N> 0. 
The state of G immediately after the k-th event [G <ex= Ureqnast: RQ, reply-to: 1 is 
expressed as 
(G is-a (FLIGHT (seats-free: N - i) (paisenger-nemertie: {lpr NAME}))) 
(by the specification of the flight actor in Figure'7-2). 
This 1s the state of G when the k + 1 st message [request: RQus4 reply-te: ?]] arrives at G. 
By the: “guaranteed . isabel access” property of -G,‘the event — 
E © [FO <ax [request 8G, reply-toe?t} 
always takes place. From ne induction Wy cellar the state bd FD at ne time of this event | 
E is expressed as : 
(FD is-a (FL Ich T-DATA (seats-free: N) Geciacacermaia: {pni}))) 
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Therefore, by the specification for FD in Figure 7.4, the state of FD after the invocation 
initiated by the event E is expressed as 
(FD is-a (FLIGHT-DATA (scats-free: N = 1) (passenger-name-list: {8pni NAME}))) 

We now claim that this is indeed the state of FD at the time the k + I st message 
[request: RQ, 44 reply-to: 7] arrives at FD. This claim is justified by the fact that no message 
arrives at FD between [request: RQ, reply-to: 7) and [request: RQq43 reply-to: 7). This fact is 
guaranteed by two properties of a one-at-a-time serializer, the "Confinement of resource” 
and the "First Come First Resource Access” (Property-III). 

Other cases are shown in a similar fashion. (End of Proof) 


The above proof relies on the following facts: 

(i) When the one-at-a-time serializer G encasing the flight data actor FD is created, each 
component [such as seats-free and  passenger-name-list]) of the conceptual 
representation expressing the external state of G is the same as the corresponding 
component of the conceptual representation expressing the state of FD. 

(2) As the specifications for G and FD show, such components of conceptual 
representations for G and FD change in the same way in response to the same 
request, provided that FD is used serially. 

(3) The serial use of the resource encased by a one-at-a-time serializer. 

(4) The "Resource Confinement” property of serializers. 


(5) The "First Come First Resource Access" property of a one-at-a-time serializer. 


7.4 Verifying Implementations of Actors Il 


In the previous section, we discussed the verification of implementations which use 
one-at-a-time serializers. The resource actor encased by a one-at-a-time serializer receives 
requests in the same order as the one-at-a-time serializer does. That is, the one-at-a-time 


serializer have the first come first resource access property [Property-III in Section 7.2]. In 
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this section, we will discuss the verif ication of icoplarientatiohi using serializers which do 
not have the first come first resource access property. The heart of verification in this case 
is the use of implementation invariants, as it was in the case for ‘implementations using 
one-at- a-time serializers. To find an appropriate implementation. invariant for a given 
implementation requires human ingenuity. In what follows; we wil explain the verification 
“of an implementation of a bounded buffer. against the specification Gepeeee in. Figure 75. 
(This specification is identical to the one given in ‘Figures 6.4 and 65.) 


‘N 


7.4.1 An Implementation of A Bounded Buffer 
We consider the following PLASMA implementation of.» bounded buffer. 
(create-bounded-butter: om 2 eee eee (ereate-string-storage (ip) 


Namely, the bounded buffer of length N is implemented asa serializer B which encases a 
string storage actor S$ where $ is created by [ eravte-strinecstorage «= Oy and B is created by 
[create-butfer-scheduler <x SJ. Note that S$ is encased by 8 without becoming known to 
other actors. Thus the resource confinement property of serializers is satisfied. 

The behavior of the String storage actor $ is described by the speifiation i in 
Figure 7.6. Its states are expressed by conceptual representations of the following form. 


(STRING-STORAGE {[...}) 


When it is created, it contains no character. It accépts (eppend: <cheractér>) and (remove:) 
messages. As stated by assertions of the form (Ss ie-used-sorially) in the where clauses, the 
behavior described in the specification is guaranteed only when Sis used serially. 

The creation of the serializer 8 is described by the following event specif ication. 
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Fig. 7.5. A Specification of A Bounded Buffer 


<event: [[ create-bounded-butfer <= [J] 
<return: B*> 
<post-cond: (B is-a (BOUNDED-BUFFER (qq! fia, UMetring: cM» » 


<erent: [B <= MJ] 
where M = [request: (remove:) reply-to: C] - 
(Case-1: <pre-cond: (B is-a (BOUNDED-RUFFER (a4: (Mayet Uy) Matring: []))) > 
<next-cond: (B is-a (BOUNDED-BUF FER. (a! [)M¢,: (fy M)Msering: []))) > 
<caused-events: {} >) 

(Case-2: <pre-cond: (B is-a (BOUNDED-BUFF ER on Oe: ()Mstring: [X > > 
<next-cond: (B is-a (BOUNDED-BUFFER (q,:-4)e, [))Gtring: [$8]))) > 
<caused-event: [C <= (removed: X)J 3} 2: 

(Case-3: <pre-cond: (B is-e (BOUNDED-BUF FER (q,: [MM §x)Mq,: (])(string: [X $s}))) 

(length([X §s}) = N) 

(MM = [request: (append: XX) reply-to: CC)) > 
<next-cond: (B is-a (BOUNDED-BUFFER (q,:Tax}Xq, [etring: [fs XX]))) > 
<caused-events: {[[C <= (removed: X}}, [CC <= (append-done:)]} >) > 


<erent: [B <= M]] 
where M = [requeat: (append: X)-reply-te: C) 2 
(Case-1: <pre-cond: (B is-a (AOUNDED-BUF FER (q,: Exe tring {#s)))) 
(length([#s)) = = N)> 
<next-cond: (8 is-a (BOUNDED-BUF F ER (a! [ix M)Xa,-: (string: [!8]))) > 
<caused-events: {} >) 
(Case-2: <pre-cond: (B is-a (BOUNDED-BUF FER (ae? iar (string: [48))) 
(length([fs]}<N)> 
<next-cond: (B is-a (BOUNDED-BUFFER (q,: (Xa. (Mstring: [Ys X}))) > 
<caused-event: [C <= (append-done:)} >) 
(Case-3: <pre-cond: (B is-a (JOUNDED-BUFFER (q,: (ae {MM by] Mstring: [}))) 
(MM = [request: (remove:) reply-to: CC]) > 
<next-cond: (B is-a (BOUNDED-BUFFER (q,: (Me (fy) (sering: []))) > 
<caused-events: {[ C <= (append-done:)]], [CC <= (removed: X)J}} >) > 
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Fig. 7.6. A Specification of a String Storage of Length N 


<event: [ create-string-storage <= [J] 
<return: $* > 


<post-cond: (S$ is-a (STRING-SPORAGE [})) >> 


<event: [[S <= (append: X)]} 
where (S is-used-serielly) — 
(Cane-I3 <pre-cend: (S is-a (STRING-STORAGE [§x))) 
(length{x) <N): > - ; 
<return: (append-done:) > 
<past-cond: (S isa (STRING-STORAGE [ix x) >) 
(Case-2: <pre-cend: (S is-a- ASPRING-STORACE te) ; 
(length(x}2 Ny > 
<roturny (storage-full:) > 
<post-cond: (S is-a (STRING-STORAGE tn »)> 


<event: [S <= (ramove:)] 
. where (S is-used-serially) . 
(Case-1: <pre-cond: (S is-a (STRING-STORAGE [X $§x))) > 
<return: (removed: X) > 
_ Spost-cond: (§ js-a (STRING-STORAGE {8x X]})) >) 
(Case-2: <pre-cond: (S is-a (ST: RENG-STORACE ba »- 
<return: (storage-empty:) > 


<post-cond: (S is-a (STRING-STORACE {f)) >}> 


<event: [ create-buffer-scheduler <= SJ} 
<pre-cond: (S is-a (STRING-STORAGE [1x])) > 
<return: B™ > 
<post-cond: 


(B is-a (SCHEDULER (counter: 0)(G,: (JMG 2 [)eromd:- {})(resource: $))) 
(Sf is-a (STRING-STORAGE [8x}))>> 


As expressed by the conceptual representation in the <post-cond:..> Clause, this serializer has 


a counter (initially 0), two queues, Ga and q, (both are initially empty) and a crowd (also 
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initially empty). The counter is used to record the number of characters stored in the string 
storage. The crowd is used to contain buck passers. The existence of a buck passer in the 
crowd indicates that the resource is being used. 4, and qr ate used to record suspended 
(append:...) and (remove:) requests, respectively. 

The behavior of the serializer B in response to (append:...) and. femstal requests 
are described the event specifications depicted in Figure 7.7 and Figure 7.8, respectively. 
Let us look at the behavior of B when it receives a message M of the form — 

‘[request: (append: X) reply-te: C). 


Case-l: if no (append:) requests are suspended lie. Ge is empty], the string Storage S is 
not being used [i.e. the crowd is empty], and there is room for the new character X [k < N],_ 
then the (append: X) request with a newly created buck passer BP which remembers the 
original continuation C is sent to S. The state change of B reflects this: the counter is 
increased by one and the crowd now contains the buck passer BP. 

Case-2: if the conditions for Case-1 do not hold, the message M is enqpesien at the rear 
of F,. 


Figure 7.7 also includes the apettaten of the event in which the reply 
(append-done:) from S in response to an (append:) request. is received by the buck passer BP 
which is currently stored in the crowd of B. When BP receives laxpand dead’: the request 
suspended in the front element of either q, or Ve is picked up and sent to the string 
storage. If both queues are not empty, 7, has priority over ,.. There are three cases for 
this event. Note that the counter k indicating the current length of the string storage 
cannot. be 0 when BP receives an (append-done:) reply, because a new character has been 
just appended before the reply is produced. | 


Case-l: if no (remove:) requests are suspended [ie. 7, is empty], and either the string 
storage is full [i.e k = N] or no (append:..) requests are suspended Lie. 7, is not empty], then 
the reply is returned to the original continuation remembered. by the buck passer P, but no 
message is sent to S. 

Case-2: if there are some suspended (remove:) requests. lie. 9, is not empty], then the the 
front element M of 9 7, is taken out, and the corresponding (remove:) request is sent to S with 
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Fig. 7.7. The Behavior of the Scheduler in response to an (Append:..) Request 


<event: [B <== MJ where M = [request: (append: X) reply-to: C} 
(Case-}: 
<pre-cond: (B is-a (SCHEDULER (counter: k\(9,: OMG [ty] Meroted: {})\(resource: S))) 
(k < N)> 
<next-cond: (B is-a (SCHEDULER (counter: k + 1)(@,: [J@- Hy] Merowd: {BP*})(resource: $))) 
(BP is-a (BUCK-PASSER (continuation: C)(serielizer: B)))> 
<caused-event: [S <a= {[request: (append: X) reply-to: BP]] >) 
(Case-2: 
<pre-cond: (B is-a (SCHEDULER (counter: KX@9:-(Ex}44,: [ly] (crowd: {!2})(resource: $))) . 
(v (x # []) (z # {}) (k= ND) > 
<next-cond: (B is-a (SCITEDULER (counter: k)(7,: (fx MJM@e- [fy] (crotod: {1a} resource: $)))> 
<caused-crents: {} >)> 


<event: [BP <s= [reply: (anpend-done:)]]] 
where (BP is-a tRUGKS PASSER (continuation: C)(serializer: B))) 
(Case-]: 
<pre-cond: (B is-a (SCH EDULER (counter: k)(@,: (xX) 5 (]crowd: {BP})(resource: $))) 
(vy (KEN) (COCKCN A x=[}) )> 
<next-cond: (B is-a (SCHEDULER (counter: k)(@q: (xJM@¢ [](erowd: {})(resource: S))) ze 
<caused-event: ‘Ic <z= [reply: (append-done:)]] >) 
(Case-2: 
<pre-cond: (B is-a (SCILEDULER (counter: k)(F,: (8x))(9,: [M ly] (crowd: {BP})(resource: S))) 
(k > 0) 
(M = (request: (remove:) reply-to: CC})> 
<next-cond: (B is-a (SCHEDULER (counter: k = 1)@q: (x)(92 [Ly] crowd: ites) ecesaton $))) 
(NBP is-a (BUCK-PASSER (continuation: CC)(serializer: B)))> 
<caused-cvents: {['S <e= (request: (remove:) reply-te: NBP] [C <e= [reply: (eppend-done:)}]] }>) 
(Case-3: 
<pre-cond: (B is-a (SCHEDULER (counter: kG: (M §x)}(9,: [])(crowd: {BP})(resource: $))) 
(0<k<N) 
(M = [request: (append: XX) reply-to: CC)) > 
<next-cond: (B is-a (SCITEDULER (counter: k + 1)(9,: (8x]G,- (])(erowd: {NBP*})(resource: $))) 
(NBP is-a (BUCK-PASSER (continuation: CC) serializer B))»> . . 
<eaused-erents: {[S <e= [request: (append: XX) reply-to: NoPT] (Cc; <= [reply:. (append-done: )30 }>)> 
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Fig. 7.8. The Behaviors of the Scheduler in response to a (Remove:..) Request 


<event: [[B <s= MJ] where M = [request: (remove:) reply-to: C) 
(Case-1: 
<pre-cond: (B is-a (SCHEDULER (counter: kG q: (EX)G- (TMerowd: {})(resource: S))) 
(k > 0)> 
<next-cond: (B is-a (SCHEDULER (counter: k - 1G q: (Ex)4- (Merowd: {BP*})(resource: S))) 
(BP is-a (BUCK-PASSER (continuation: C)(serializer: B)))> 
<caused-event: [S <== [request: (remove:) reply-to: BP] >) 
(Case-2: , 
<pre-cond: (B is-a (SCHEDULER (counter: kG: (EXJG: [Ly] crowd: {#2})(resource: S))) 
(v {y # []) (z # {}) (k = 0))> 
<next-cond: (B is-a (SCHEDULER (counter: k)\(@q: (1x): [ty M] (crowd: (ayieanaaree $)))> 
<caused-ervents: {pp 


<event: [ BP <== [reply: (removed: X)]] 
where (BP is-a (BUCK-PASSER (continuation: C)(serializer: B))) 
(Case-]: 
<pre-cond: (B is-a (SCITEDULER (counter: k)\(Gq: (1G [ty] Merowd: {BP})(reaource: S))) 
(v (kK=0) (Q<kK<N A y=[J) )> 
<next-cond: (B is-a (SCHEDULER (counter: k)(G 4: (M4, [Ly] crowd: {})(resource: $))) > 
<caused-event: [C <== [reply: (removed: X)J]] >) 
(Case-2: 
<pre-cond: (B is-a (SCHEDULER (counter: k)(q,: [M §x))(92 [fy] Merowd: {BP})(resource: S))) 
(k < N) 
(M = [request: (append: XX) reply-to: CC])> 
<next-cond: (B is-a (SCHEDULER (counter: k + 14: [JG - [Ly] (crowd: {NBP*})(resource: $))) 
(NBP is-a (BUCK-PASSER (continuation: CC)(serializer: B)))> 
<caused-erents: {TS <== [request: (append: XX) reply-to: NBPJ]] [C <== [reply: (removed: X)}]) >) 
(Case-3: 
<pre-cond: (B is-a (SCHEDULER (counter: k)(9,: (12, [M by] (crowd: {BP})(resource: $))) 
(0 <k<N) 
(M = [request: (remove:) reply-to: CC]) > 
<next-cond: (B is-a (SCHEDULER (counter: k = 1)(G 4: (4, (fy) Merowd: {NBP*})(resource: $))) 
(NBP is-a (BUCK-PASSER (continuation: CC)(serializer: B)))> 
<caused-events: {LS <== (request: (remove:) reply-to: NBPJ]] [C <== [reply: (removed: X)]]] }>)> 
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a new buck passer NBP and concurrently the reply is sent to the original continuation C. 
Case-3: if no (remove:) requests are suspended [i.e. 7, is empty], there are some suspended 
(append:...) request [i.e. 7, is not empty}, and there is room for a new character in S [ie., 
0 <k<N), then the (append:...) request at the front of 7, is granted and sent to S with a 

new buck passer NBP, and concurrently the reply is returned to the original continuation C. 

It should be noted that all the three cases are mutually exclusive and enumerate all 
cases of the states which B can be in when BP receives a [reply: (append-done:)] message. _ 
The behavior of B in response to (remove:) is described in Figure 7.8 in a similar way; the 
roles of G, and @, are symmetrical and conditions expressing the upper bound for the 
counter is replaced by the lower bound. @, has priority over @, when a buck passer BP 


receives a (removed: ?) from the string storage. 


7.4.2. Verification of a Bounded Buffer 


In order to show that the implementation of the bounded buffer given in Figures 
7.7 and 78 satisfies the specification given in Figure 7.5, we need the implementation 
invariant which is the mapping between the states of a bounded buffer used to write its 
specification and the states used for describing the implementation. More precisely, we 
need the mapping from the set of states, called the “specification space”, expressed by 


conceptual representations of the form 
(BOUNDED-BUFFER (qq: [-JMag {-JMstring: [-D) 


to the set of states, called the “implementation space", expressed by conceptual” 


representations of the form 
(SCITEDULER (counter: 79 ,,: [.-1N@,; [-.]boresod: {.})(resource: S)). 


For this purpose, we use the following implementation invariant: 
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" If a bounded buffer B is in the state (of the specification space) 
. which is expressed by the conceptual representation 
(BOUNDED-BUFFER (qq: (8x) May: [ty string: [38))) 
then 
B is in one of the states (of the implementation space) 
which are expressed by the conceptual representation 


(SCHEDULER (counter: k)(@ qi (Yxx §x)(9: [Lyy Hy] Merowd: {12})(resource: $)), 
and the following constraints must be satisfied 


(1) [Istored-in(S) Icharacters~appended(xx)] = [Icharacters-removed(yy) !s]} 
(2) length(stored-in(S)) =k ” 


characters-appended(xx) means the sequence of characters that will be appended by the 
sequence of (append:...) requests denoted by xx. characters-removed(yy) means the sequence 
of characters that will be removed by the sequence of (remove:) requests denoted by yy. 
stored-in(S) means the sequence of characters stored in the string storage S. 

Note that q, and @, share x and q, and @, share y at their tails. Gq and G, denote 
the queues of requests which are actually waiting inside the scheduler. Thus xx and yy in 
Gq and 4, denote the sequences of actually suspended requests that are considered (at the 
external specification level) to have already been processed. [x and y have not been 
processed yet.) The first constraint in the above implementation invariant says: the 
concatenation of the character string that is actually stored in S and the sequence of 
characters that will be appended by xx is equal to the concatenation of the sequence of 
characters that will be removed by yy and the character string that is considered (at the 
external specification level) to be stored in string. The second constraint says that the 
counter k indicates the length of the character string stored in S. 

Since, for given x, y and s, only the relation (or constraints) that must be satisfied 


by xx, yy and k is specified, the above implementation invariant defines a one-to-many 
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correspondence from the specification space to the ainpreenitation space. (Cf. Section 5.3.1, 
Chapter 5) Namely, for a given state U in the specification space, the implementation 
invariant II give a set Il(U) of the corresponding states in the implementation Space. See 


the diagram below. 


<Specification Space> U <Implementation Space> 


To verify the implementation against the specification in Figure 75, for each event 
Specification in the specification, the implementation must be verified. The diagram in 
Figure 7.9 illustrates the verification for an event E = [[B «x= MJ. T and T’ are the states 
of the bounded buffer B given in the <pre-cend:..> and <next-cond:..> Clauses (of the event 
Specification for E), respectively. II(T)..and IMT’) are the sets of states (in the 
implementation space) obtained by applying the implementation invariant II to T and T’, 
respectively. 

To establish the event specification, we must first show that if the bounded buffer - 
B is in a state belonging to II(T) before the event E, B is in a state belonging to IK(T’) 
immediately after E. To show this, we do not have to. deal with individual states in II(T) 
and II(T"). We use the relations among the constituents of the implementation which define 


I(T) and 11(T’). (Of course, such relations are obtained from the constraints given in the 


Fig. 7.9. Establishing an 


- 179 - 


Event Specification 


E=([B <= M] 
T 


_ Specification Space> 


eee eee tere 


<Implementation Space> 
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implementation invariant] By using the description of the implementation given in 
Figures 7.7 and 7.8, ‘we obtain (from the defining relation for 11(T)) the relation which 
defines the set X of states in which B can be immediately after E. We check to see whether 
or not the obtained relation satisfies the defining relation for H(T’), i.e, we check whether 
or not X is a subset of IK(T’). If the obtained relation satisfies the defining relation for 
IK(T"), it is verified that the state of B immediately after the event E is T’ in the 
specification space. 

But this does not mean that the implementation satisfies the <next-cond:...> clause. 
We must show that the state of B in the specification space does not change until the next 
request message (either (append:..) or (remove:)) arrives at B, because at the implementation 
level (i.e, when B is considered as a scheduling serializer), a buck passer in the crowd of B 
may receive a reply message from the string storage $ and consequently, the state of B 
which is currently one of states belonging to x may not belong to IKT") after such-a reply 
event. Therefore we must also show that the state of B stays inside II(T"), which means 
that such reply events do not change the state of B in the specif ication space. To do so, we 
check if the relation defining the set Y of states in which B can be immediately after the 
resource reply event satisfies the defining relation for I(T’). 7 | 

To complete the verification of the event specif ication, we must show that the 
events given in the <caused-events:..> clause eventually take place. To do so, we use the fact 
that the sequence of requests xx in @, and the sequence of requests yy in G, are eventually 
removed and sent to S$. This is easily done by checking ‘the implementation given in | 


Figures 7.7 and 7.8 and the specif ication of the string storage given in Figure 7.6. 


8. Modelling a Post Office 


In this chapter, we discuss an actor model of a simple post office which is an 
intuitive example of systems, such as operating. systems and multi-user data base systems, 
‘which are characterized by complex concurrent internal activities. In the first section, an 
informal description of the post office is followed by formal specifications of the 
individual behavior and mutual interaction of the components of the model. In the second. 
section, the specification of the overall functions (task specifications) of the post office is 
Stated formally. In the last section, we demonstrate that the task specifications are satisfied 


by the individual behavior and mutual interaction. 


- 182 - 


8.1 A Model of a Simple Post Office 


In this section, we present the actor model of a simple post office. The behavior 
of each component in the model is described by our specif ication techniques and the overall 


properties and effects of the post office as a whole are stated. formally. Furthermore,. using 


this model as an example, we would like to shed light on some of the interesting issues 


related to distributed information processing systems. | 


8.1.1 Overview of the Model 


An informal description of activities in a simple post office is: 


A number of customers and mail collectors visit the post office, possibly simultaneously. 
The post office has only one door for customers and collectors. Inside the post office, there 
is a counter section which has several counters and a mail box corner which has a mail box. 
After a customer enters the post office through the door, if he needs stamps, he goes to the 
counter section, otherwise he goes to the mail box corner. At the counter section, a customer 
gets the stamps he needs and then, if he is carrying letters, he goes to the mail box corner, 
otherwise he goes out of the post office through the door. Customers are served at the 
counter section on a first-come-first-served basis, but the time spent at the counter varies 
from person to person. At the mail box.corner, a customer. puts. all.the letters he -has been 
carrying im the mail box and goes out through the door. A collector also enters the post 
office through the door and then goes to thé mail box corner.” At the mail box “corner, the 
collector collects all the mail in the mail box after waiting in the queue, if there is one, and 
then he carries the collected mail out of the post office through the door. Customers and 
collectors make a single queue at the mail box cories andarréve and leave the corner on 
first- ~in-f irst-out, basis. 


We model this post offi ice with five kinds of actors: customer actors, collector . 
actors, the door actor, the counter section actor, and the mail box corner actor. Gee Figure 
8.1] The movement of customers and collectors is modelted as message-passing where 
messages are customer and collector actors and targets are » the door actor, the counter section 


actor and the mail box corner actor. Components of the office, collectors and customers 
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Fig. 8.1. “customers, collectors . 
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have their own local time. Thus, arrivals of customers and collectors at these components 
are in general mutually independent. Furthermore, we assume that the walking speed of 
customers and collectors may vary from person to person. So, for example, a customer 
arriving at the door after another customer may arvive at the counter section before him. 
This corresponds to the fact that the actor model of computation assumes nothing about the 
duration of message-passing except its finiteness. Besides such concurrent events, services 
at different counters are carried out concurrently, and of course depositing and collecting 
the mail in the mail box corner takes place independently of the activities at the counter 
section. 

| In the subsections that follow, formal specifications of the behavior of each actor 


will be given and we will state the task specifications that describe the overall properties 
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and effects that are created by the interaction and individual behavior of the component 


actors. 


8.1.2 Interactions at the Door 


To formally describe the activities in the. post office, first we need to define the 
states. of actors in the model. | : . . 

For a customer, there are two internal factors which determine his behavior: the 
letters he carries and the number of stamps he needs at a given time. Thus we express the 


states of a customer actor by conceptual representations of the following form. . 
(CUSTOMER Uetters: {..}) (s-stemps-needed: 1)) 


For a collector, the effects of interactions with other actors are expressed by the collected 
mail. So the state of a collector actor is expressed by conceptual representations of the 
following form. 


(COLLECTOR (collected-mail: {..})) 


We cannot define the state of the post office as a whole in terms of the states of its 
components, because people can be in transit between the components. Customers and 
collectors may be constantly entering and exiting through the door while other customers 
and collectors may be changing the states of the. mailbox corner by depositing and 
removing the mail Only the local states of the component actors are well. defined. 
However, we can use the state of the door actor to describe useful aspects of the state of the 
whole post office if it is defined as below. . 

The state of the door actor must be defined as an equivalence class of histories of 
message sent to it. The informal description of the model tells us that customers and 
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collectors arrive at the door when they enter and exit from the post office. So we assume 
that the door actor accepts four kinds of messages: 

(customer-entering: <customer>), (customer-exiting: <customer>), 

(collector-entering: <collector>), and (collector-exiting: <collector>). 
Thus the states of the door actor are defined in terms of these kinds of messages. Since the 
states of customer and collector actors are well defined at the time they arrive at the door 
actor, their states can be used to define the state of the.door actor. This means that the 
information available in conceptual representations for customer and collector actors can be 
used. 

We define the state of the door actor at the time of message arrival by 

(I) the set of all customers inside the post office, 

(2) the set of all collectors inside the post office and 
_ (3) the set of all mail inside the post office. 
These three sets are sufficient to characterize useful aspects of the state of the post office as 
a whole and yet well defined as information local to the door actor, because, for example, 
the set of mail inside the post office is determined by the difference between letters brought 
in and letters taken out through the door by customers and collectors. We express the states 
of the door actor by conceptual representations of the following form. The key word, 


POST-OF FICE, reflects the intention that they serve as the states of the whole post office. 
(POST-OF FICE (mail: {...} (customers: {...})(collectors: {...}))) 


A formal specification of the effects of interactions between the door actor and 
customer and collector actors is depicted in Figure 82. One should note the 
<caused-event:...) clauses: After a customer actor arrives at the door actor, a message 


(go-to-counter-section-if-necessary:) instructs him to decide where to go next. Other 
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Fig. 8.2. A Specification of Interactions at the Door 


<ervent: [ the-door <= (customer-entering: C)] . (sp-1) 
<pre-cond: 
(the-door is-a (POST-OF FICE (mail: {3m}) (customers: {8cs})(collectors: {3cls}))) 
(C is-a (CUSTOMER (letters: {U})(e-of-stamps-needed: N)))> 
<next-cond: 
(the-door is-a (POST-OF FICE (mail: {tm $1})(customers: {ics C}collectors: {¥cls}))) 
(C is-a (CUSTOMER (letters: {1})(e-of-stamps-necded: N))) > 
<caused-event: [C <= (qo-to-counter-section-if-necessary!)] >> 


<erent: [the-door <= (customer-exiting: C)} . (sp-2) 
<pre-cond: 
(the-door is-a (POST-OF FICE (mail: {imi $I §m2})(customers: {¥esi C §cs2})(collectors: {Icls}))) 
(C is-a (CUSTOMER (Ulettérs: {31})(e-of-stamps-needed: N))) > 
<next-cond: 
(the-door is-a (POST-OF FICE (mail: {m1 §m2})(customers: {!cal isi stictineiata ey 
(C is-a (CUSTOMER (letters: {81}Nie-ef-stemperneeded: Aa > 
<caused-erent: [street <= C]] >» 


<erent: [ the-door <= (collector-entering: CL)] (sp-3) 
<pre-cond: 
(the-door is-a (POST-OF FICE (mail: {4m})(customers: {tes} collectors: {3cle}))) 
(CL is-a (COLLECTOR (collected-mait: {8em}))) > 
<next-cond: 
(the-door is-a (POST-OF FICE (mail: {3m tcm})(eustomers: {3es}Mcollectors: {leis CL}))) 
(CL is-a (COLLECTOR (collected-mail: {Yem}))) > 
<cansed-event: [ mail-box-corner <= (collectors: CL) >> 


<enent: [ the-door <= (collector-exiting: CL)] , (sp-4) 

<pre-cond: , 
(the~door is-a (POST-OF FICE (mail: {m1 fem §m2})(customers: {3cs})(collectors: {¥cls1 CL #ci2}))) 
(CL is-a (COLLECTOR (collected-mail: {4em}))) > 

<next-cond: 
(the-door is-a (POST-OF FICE (mail: {1m1 Im2})(custemers: pean {Iclsi 8cls2}))) 
(CL is-a (COLLECTOR (collected-mail: {fem}))) > 

<caused-event: [street <= CL] >> 
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<caused-event:...> Clauses indicate where a customer or collector actor is sent after it arrives at 
the door. In particular, customers and collectors are sent to the street actor after they exit 


from the post office. 


8.1.3 Interactions at the Counter Section 


Upon entering the post office, a customer must decide where he should go, i.e. to 
the counter section or the mail box corner. The decision is made in response to a message 
(go-to-counter-section-if-necessary:), according to whether or not he needs stamps. This 


behavior of the customer is expressed by the following event specification. 


<event: [C <= (go-to-counter-section-if-necessary:)] (sp-5) 
(Case-1: 
<pre-cond: 
(C is-a (CUSTOMER (letters: {$1})(#-of-stamps-needed: N))) 
(N > 0)> 
<next-cond: (C is-a (CUSTOMER (letters: {31})(#-of-stamps-needed: N)))> 
<caused-event: [ counter-section <= (customer: C)]) >) 
(Case-2: 
<pre-cond: (C is-a (CUSTOMER (letters: {81})(#-of-stamps-needed: 0))) > 
<next-cond: (C is-a (CUSTOMER (letters: {41})(e-of-stamps-needed: 0)))> 
<caused-event: [[ mail-box-corner <= (customer: C)]} >)> 


Two points should be made. about the specification above. First, the customer C sends 
himself to the counter section or the mail box corner. Second, the customer C does not. 
change his state as described in the <next-cond:...> Clauses. 

| The effects of interaction between customers and the counter section are described 


by the following simple event specification. 


~ 188 - 


<event: [counter-section <= (customer: C)] - 3 (sp-6) 
<pre-cond: (C is-a (CUSTOMER (letters: {81})(s-of-stamps-needed: N))) > 
<next-cond: (C is-a (CUSTOMER (letters: {¥1})(s-0f-stamps-needed: 0))) > 
<caused-event: [C <= (go-to-mail-box-corner-if-necessary:)]} >> 


This specification might look too simple. Of course, by using conceptual representations 
for the counter section which include more detailed information, we could express various 
activities and interactions such as customers waitirig ina queue, and buying stamps at a 
counter. Also, we could define the state of the counter section in a way similar to that in 
which we defined the sates of the door actor. But for our present purpose, the event 
specification above is sufficient. . 

When a customer leaves the counter section, he must again decide. where to go 
next, the mail box corner or the door. The decision is made in response to a message 
(q0-t0-mail-box-if-necessary:), according to whether or not he is carrying letters. This is 
expressed as follows. 

<event: [[C <= (qo-to-mail-box-corner-if-necessory:)] (sp-7) 

(Case-I: 
<pre-cond: 
(C is-a (CUSTOMER (letters: {4\})(#-of-stamps-needed: N))) 
(18} o {}) > 
<next-cond: (C is-a (CUSTOMER (letters: {$1})(s-of-stamps-needed: N))) > 


<caused-event: [ mail-box-eorner <= (customer: C)} >) 

(Case-2: 
<pre-cond: (C is-a (CUSTOMER (letters: {})(#-of-stamps-needed: N))) > 
<nexi-cond: (C is-a (CUSTOMER (letters: {})(e-of-stempa-needed: N))) > 
<caused-event: [ the-door <= (customer-exiting: C)]. >> 


Note that no conditions are made for the number of stamps needed N in the 
preconditions in the above specification. [See, Section 8.1.5 
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8.1.4 Interaction at the Mail Box Corner 


To complete the local specifications, we must specify the interaction between the 
mail box corner and its users. An important fact stated in the informal description of the 
model is that customers and collectors wait in the same queue before the mail box and that 
they deposit or collect mail on a first-in-first-out basis. This fact allows us to define the 
State of the mail box corner by the set of letters brought by the customers who arrived at 
the mail box corner after the collector who arrived most recently. Letters brought do not 
necessarily mean letters that are already put in the mail box. They may still be carried by 
customers in the waiting queue. We use conceptual representations of the following form 
for the mail box corner. (MAIL-BOX-CORNER (posted-mail: {..})) | The interaction is 


described by the event specifications in Figure 8.3. - 


Fig. 8.3. A Specification of the Interactions at the Mail Box Corner 


<event: [ mail-box-corner <= (customer: C)]] (sp-8) 
<pre-cond: 
(mail-box-corner is-a (MAIL-BOX-CORNER (posted-mail: {4m}))) 
(C is-a (CUSTOMER (letters: {1})(#-of-stamps-needed: N))) > 
<next-cond: 
(mail-box-corner is-a (Af{AIL-BOX-CORNER (posted-mail: {'m "}))) 
(C is-a (CUSTOMER (letters: {})(#-of-stamps-needed: N))) > 
<caused-event: [ the-door <= (customer-exiting: C)] >> 


<event: [[ mail-box-corner <= (collectors: CL)]] (sp-9) 

<pre-cond: , 
(mail-box-corner is-a (Af AIL-BOX-CORNER (posted-mail: {5m}))) 
(CL is-a (COLLECTOR (collected-mail: {4em}))) > 

<next-cond: , 
(mail-box-corner is-a (MAIL-BOX-CORNER (posted-mail: {}))) 
(CL is-a (COLLECTOR (collected-mail: {fem 'm}))) > 

<caused-cvent: [[ the-door <= (collector-exiting: CL)]] >> 
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8.1.5 Assumptions of No Implicit Interactions 


In addition to the above specifications of local interactions, we must make the 
following assumptions of global nature to describe the post office model completely. 


Assumption-I 
Customer and collector actors do not receive any messages except those explicitly 


Stated in the event specifications sp-l to sp-9. 


Assumption-IT 
The counter section actor and the mail box corner actor interact with only the 


customer and collector actors which have entered through the door. The door 

‘ actor interacts with only the: (eustomer-eriting:...) ahd (collector-exiting:...) Messages 
which contain collector or customer actors which have entered through the door. 
(No. customer or collector actor can arrive directly at these actors without going 
through the door.) 


The first assumption implies that customer or collector actors do not change their states 
immediately after an event E until the event caused by E, where E is one of the events 
specified by sp-l to sp-9. For example, immediately after the event 
[counter-section <= (customer: C)]], the state of a customer C which is stated in the 
<next-cond:..> Clause of the event specification sp-6 do not change until C receives the 
(go-to-mail-box-corner...) message. Thus, in the events specification sp-7, the number N of 
Stamps needed (by the customer C) is zero, because it was zero immediately after 


[counter-section <= (customer: C)]] as stated in the <next-cond:..> clause of sp-6. 
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8.2 Task Specifications 


We have specified the individual behavior and mutual interaction of actors in the 
post office model. These specifications are local in nature. In this section, we will state 
some of the overall [global] task specifications of the post office that should be implied by 
the local specifications. It is important that such task specifications be stated in terms of 
externally visible actors because the function of the post office should be specified and 
understood without knowledge of the details of what is going on inside. These actors are 
the door actor, and customer and collector actors which are outside the post office. 
| Four task specifications of the post office are in order. For each task specification, 


an informal statement is followed by the formal one. 


The first task specification is expressed in terms of a customer's two states: one 
before he enters the post office and one after he exits. This may be considered as a 
specification of the function of the post office from the view point of a customer. 
Task-I_ (Customer is Guaranteed to Return without Letters) 


If a customer visits the post office, he must eventually leave there. When he leaves the 
post office, he must not be carrying letters and he does not need stamps. 


<event: [ the-door <= (customer-entering: C)]] 
<pre-cond: (C is-a (CUSTOMER (letters: {11))(e-of-stamps-needed: N))) > 
<caused-event: [street <= C] > 
<post-cond: (C is-a (CUSTOMER (letters: {})(#-of-stamps-needed: 0))) >> 


The second task specification is the collector version of the first one 
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Task-Il (Collector is Guaranteed Not to Lose Any Mail) 

If a collector visits the post office, he must eventually leave there. When he leaves the 
post office, he must be carrying the newly collected mail [which may be empty) in addition 
to the mail he brought into the post office. 


<ervent: [ the-door <= (collector-entering: CL)]] 
<pre-cond: (CL is-a (COLLECTOR (collected-mail: {4¢m1}))) > 
<caused-event: [street <= CL )] > 
<post-cond: (CL is-a (COLLECTOR (collected-mail: {...8em1...}))) >> 


The next task specification is expressed in terms of the interaction between 
customers and collectors through a set of letters. This may be considered as a specification 


of the function of the post office from the view point of individual letters. 


Task-]Il (Guaranteed Collection of Mail) 
Suppose that a set {8m} of letters is brought into the post office by a customer C. 
Then if there is a collector CL who enters the post office after the customer C leaves, 
then there always exists a collector CLL (who may be the collector CL) who brings the set 
{!m} of letters out of the post office to the street. 


For an event E._enter = Lthe-door <= (customer-entering: C)] 
where (C is-a (CUSTOMER (letters:{4m})(#-of-stamps-needed: N))), 


if there exists an event E-i-enter = [ the-door <= (collector-entering: CL)]] 


such that Ecenter ~act=> Ecjenter “8°'"?the-door Fe-exit 
where E..yit = [the-door <= (customer-exiting: C)], 


then there must exist an event E.1.ctpeet = Lstreet <= CLL] 
such that (CLL is-a (COLLECTOR (collected-mail: {...4m...}))). 
It should be noted that the mail of a customer C could be collected even if no collector 
enters the post office before C leaves. But in this case there must be some collector which 
arrives at the mail box corner after C arrives there. (Of course. this cannot be stated in the 
task specification because the mail box corner which is an internal component of the post 


office should not be mentioned in the task specifications.) 
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The next task specification is expressed in terms of the states of the-door (more 
precisely, sets of mail inside the post office) at different times. This task specification is 


derived from Task-Ill. 


Task-1V_ (No Stagnation of Mail) 

Let UM, UC and UCL respectively be the set of letters, the set of customers, and the set 
of collectors inside the post office in a given situation S. If there is a collector CL who 
enters the post office after all the customers UC and all the collectors UCL (who were 
inside the post office in the situation S) leave the post office, the set of letters which are 
inside the post office after the collector CL leaves does not share any letters with the set UM 
of letters (that were inside the post office in the situation S). 


Suppose that 
(the-door is-a (POST-OF FICE (mail: {§m})(customers: {§cs})(collectors: {{cls}))) holds 

in S = Sit{[[ the-door <= MJ]. 

If there exists an event E = [the-door <= (collector-entering: CL)]} 
such that . 

for any customer C; in {!ces} and any collector Cl; in {!cls}, 
the following ordering relations hold 
Ec; “8 the-door E and Eq); “@rr->the-door F 


where Ee, = [the-door <= (customer-exiting: C;)] 
Eel; = [[ the-door <= (collector-existing: cL]. 


then for any event EE = [ the-door <= MM] 
such that E -arr->tno-goor E "8°"? the-door EE or E’ = EE 
where €’ = [[ the-door <= (collector-exiting: CL)], 
it is the case that 
(the-door is-a (POST-OfFICE (mail: {8mm})(customers: {...})(collectors: {...}))) holds 
in Sit{EE] where {im} N {Emm} = ¢ 
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8.3 Verification for the- Task Specifications - 


In this section we will demonstrate that the event specifications, which are given in 
Sect 8.1 as the description of the behavior of individual actors in the model and their 
interaction, satisfy the task, specifications in the. previous section, Also, some of the 
interesting properties. of. the. event Ee eee given in Sectton 84 will be revealed in the 


course ot the verification. 


8.3.1 Verification for Customer's Guaranteed Return without Letters 


First we will verity the following task Specification. Some of the properties 
observed in the process of the verifi ication will be used later in the verification for other 


task specifications. 


Task-1 (Customer's Guaranteed: Return without Letters) 
<event: [[ the-door <= (customer-entering: | a 
<pre-cond: (C is-a (CUSTOMER (letters: eecar Somme motet: N))) > 
<caused-event: [street <#:CJ >) 2 2 oe 
<post-cond: - (C is-a (CUSTOMER (letters: (Meef-wemprneeded: 0))) >> 


(Verification) This task specification is established by tracing sequences of events which 
involve a customer actor. Such sequences are obtained by “checking. causal relations among 
events described by the event spécifications given in Sect 81. Tracing such a sequence can 
be done by examining (local) states of actors Participating . in each event, but certain 
cautions are necessary in dealing with the state of. the-deor actor which represents external . 
state of the whole post office. Furthermore, it should be noted in the following 
demonstration that the reasoning from one event to another crucially depends on 
Assumption-I in Section 815. Namely, we assume that the state of a customer C does not 
change from an event E to the next event caused by E. Below this assumption will be used 
without being mentioned. 


First we assume that an event E,. 16, takes place as described below. 
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center’ [the-door <= (customer-entering: C)]} | 
where (C is-a (CUSTOMER (letters: {1})(e-of-stamps-needed: N))) 
(the-door is-a (POST-OF FICE (mail: {1m})(customers: {'cs})(collectors: {'cls}))) 


The event Epnrer and the first assertion’ are assumed by the task specification to be 
verified, and the second assertion is assumed in the <pre-cond:..> clause in the event 
specification sp-l. Note that as sp-i specifies, the state of the-door immediately after this 
event is expressed as 

(the-door is-a (POST-OF FICE (mail: {fm '}Meastomers: {§cs C})(collectors: {4cls}))) 
which means that the customer C is now inside the post office. The <caused-event:...> and 
<next-cond:..> Clauses of sp-1 tell us what will happen to C next and what state C will be in. 


E decisionst: [Cc <= (qo-to-counter-section-if-necessary:)] | ; 
where (C is-a (CUSTOMER (letters: {11})(e-of-stamps-needed: N))) 


To know what event will take place after Ey sion} the event specification sp-5 is referred 
to. Two cases need to be considered: (I) Epounter is caused if N>Oand (2) Enais-box is 
caused if N= 0. 


Ecounter: [eounter-section <= (customer: C)]. 
where (C is-a (CUSTOMER (letters: {3\})(#-of-stamps-needed: N))), (N > 0). 


The event specification sp-6 tells that the following event Enecision-2 is caused by Ecuater 
and that the number of stamps needed becomes zero. 


cE decision-2: ‘[c <= (go-to-mail-box-corner-if-necessary:) ]). 
where (C is-a (CUSTOMER (letters: {5\})(#-of-stamps-needed: 0))) 


To know what event will take place next, the event specification sp-7 is referred to. We 
need a case analysis: (1) E,.,i1-box is caused if I # {} and (2) E,y;, is caused if | = {}. 


E nail Pe [ mail-box-corner <= (customer: C)] 
where (C is-a (CUSTOM ER (letters: (2 e-of-stampe-neaded: 0))) 


Note that E,)si1-box is also caused by Eqecision-1 a5 Well a8 Egecision-2° Both Egecision-1 
and Evecision-2 insure that the number of stamps needed is zero. On the other hand, the 
letters {8} the customer C is carrying may or may not be empty, because Eqecicion-2 insures 
that | is not empty, but Eqecision-; does not. The. event specification i tells us the next 


event Eoy it 
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Foxit! [[ the-door <= (customer-exiting:C)]] . 
where (C is-a (CUSTOMER (letters: {}}(e-0f-atampa-noeded: N))) 
(the-door is-a (POST-OF FICE (mail: {..}Meustomers: {...C...})(collectors: {...}))) 


The first assertion is guaranteed by the <next-cond:..> clause of the event specification sp-8. 
The second assertion that the customer C is still inside the post office must hold in order 
for the event specification sp-2 to be applied. This assertion is guaranteed by the eons 
facts: 
(1) Examining all the event specifications sp-] through sp-9, events of the form 
[the-door <= (customer-exiting: C)] are the only way for C to exit from the post office 
(i.e. to eliminate C from the (customers: {...}) component of the coneeprial representation 
for the door actor). 
(2) An event of the form [the-door <= (customer-exiting: C)J) have not taken place since 
C entered the post office. 
Now the event specification sp-2 insures the following event E,..., will happen and the 
assertion will hold. 


Estreet: Lstreet <= CJ 
where (C is-a (CUSTOM ER (letters: e-of-stame-necded: 0))) 


The causal relations among the events — through Erect are illustrated as 
follows 


E 


=--> 


enter Edecision-| ~~? Emait-box ~~> s Eexit “> Estreet 


e 
t r @ 
‘ t gf 


. hg ee . 

Ecounter ~~> Edecigion-2 
Since all the event specifications used in the above discussion guarantee that the events 
given in their <caused-event:..> clauses always take place, Estreer 8 guaranteed to take place. . 
And the state of the customer.C in the situation E.srog: is aay what is required by the 
task specification. . ~ (End of Verification) 


The second task specification given in the previous section can be verified in the 
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same way as above. In fact, applications of the event specifications sp-3, sp-9 and sp-4 in 
this order will do, It should be noted that in using the event specification sp-4, a 
justification similar to the one we made, in the reasoning from Esyit t© Estreet for 


applying the event specification sp-2 is necessary. 


8.3.2. Verification for Guaranteed Collection of Mail 


Task-III (Guaranteed Collection of Mail) 


For an event Eoenter = [ the-door <= (customer-entering: C)]} . 
where (C is-a (CUSTOMER (letters:{1m})(e-of-atampe-necded: ?))), 
if there exists an event Eqjenter = Lthe-door <= (collector-entering: CL)]] 
such that Ec. enter ~act=> Ec-gxit “"">the-door Eci-enter 
where E..9,i¢ = [the-door <= (customer-exiting: C)], 
then there must exist an event E = [ street <= CLL] 
such that (CLL is-e (COLLECTOR (collected-mail: {...4m... }))) holds. 


To verify this task specification, we rely on the following lemma which is easily 
derived from the event specifications given. in Sect 81. This lemma guarantees that if a 
customer enters the post office carrying a set {H} of. letters, he always arrives at the mail 


box corner carrying the same set of mail. — 


Lemma 


For an event Ec. enter = [the-door <= (customer-entering: C)] 
where (C is-a (CUSTOMER (letters: {81})(s-of-stamps-needed: 7))), 
there always exists an event Ecemail-box = = [ mail-box-corner <= (customer: C)]] 
where (C is-a (CUSTOMER (letters: {8l}Ne-0f-stamps-needed: ?))) 
such that E 


center ~8¢t-> Ec-mail-box . 
This was justified during the verification of the first task specification. 


[Note that Eonter > Email-box in the demonstration of Task-I.J 
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(Verification of Task-IIl) 
Suppose that an event E.. oie, = [the-door <# (customer-entering: C)]] takes place 
where 
(C is-a (CUSTOMER (letters: {11})(e-0f-stampa-needed: ?))) 
holds. By the above Jemma, an event Emalicbox = [ mail-box-corner <= (customer: c)] 
always takes place and the same assertion 
(C is-a (CUSTOMER (letters: {8\})(#-of-stemps-needed: 7))) 
still holds. Here we assume that the following assertion holds when E._ 1, ij-pox 
(mail-box-corner is-a (AM AIL-BOX-CORNER (posted-mail: {tpm}))). 
Then, by the event specification sp-8, the assertion 
(mail-box-corner is-a (M AIL-BOX-CORNER (posted-mail: {4pm 11}))) 
holds immediately after E,.nsyepo, and until the next message arrival at the 
mail-box-corner. Sp-8 also guarantees that E cenit = Lierdooe te (customer-exiting: C)]] will 
take place. 
Then suppose that the following: event takes place after E-.9,i¢ 
Ecteenter “Lthe-door <= (collector-entering: CL)} 
where cha is-a (COLLECTOR (collected-mail: {tem}i)) | holds. By the event specification sp-3, 
Es culicoay. = ‘[[mail-box-corner’ <x (collectors: cL) 
takes place where (CL is-a (COLLECTOR (collected-meail: {tcm}))) still holds. At this point, 
the ordering of the events which have already occurred is expressed as follows. 


takes place. 


Eceenter ~2¢t-? Ec -meit-box “#tm> Ecngyit “8 theedeor Ecleenter “28t-? Ecj-mail-box 


The important fact here is that E..nsitebo, precedes E.jnauebox We shall consider two 

cases: 

Case-l: If any collectors do not arrive at the mail box corner, between Eoomaitebox | and 

Eel-mail-box: the state of the mail box corner. at the time of. Eei-mail-box is expressed as 

(mail-box-corner is-a (AL AIL- ~BOX-GORNER (posted- -mail: {-Ipm... §1...}))) 

because customers arriving between. p SORT OE and Ect ewintlbiox- only deposit, but never 

collect mail. Then as the event specification sp-9 states, the collector CL. collects. all the mail 

{...Epm..H...} and then go to the door. 

Case-2: If there are collectors who arrive at the mail box: corner between eo nee and 
Eej-mail-box: then the first one among such collectars will collect the mail which includes {81} 

and {! ee and then go to the door. 
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In both cases, some collector carrying {HI}, say CLL, arrives at the door from the 
mail box. To insure that the collector CLL goes out to the street, the two assertions given in 
the <pre-cond:..> clause of the event specification sp-4 must be satisfied. One assertion says 
that CLL must be one of the collectors who appear in the conceptual representation of the 
door actor at the time CLL arrives, namely, the following must hold. 

(the-door is-a (POST-OF FICE (mail:{...})(customers:{...} (collectors:{..CLL...}))). 
Assumption-ll in Section 8.1.5 guarantees that this assertion holds, because it assumes that 
all the collectors arriving at the door from the mail box corner must have entered thraugh 
the door, so by sp-3 CLL must appear in the (collectors:..) component of the conceptual 
representation of the door. This completes the verification. Note that Assumption-I was 
used throughout the above demonstration. (End of Verification) 


The last task specification "No Stagnation of Mail” can be verified by using 
already established task specifications. As was done in this task specification, let us suppose 
that the state of the post office is expressed by the following assertion. 

(the-door is-a (POST-OF FICE (mail: {!m})(customers: {!es})(collectors: {3cls}))) 
Then it is the case that every letter | which is an element of the mail {!m} inside the post 
office is brought in either by a customer or by a collector. If | is brought in by a customer, 
we can use the third task specification which has been just established above. If | is 
brought in by a collector, the second task specification "Collector is Guaranteed Not to Lose 
Any Mail” insures that | will be brought out by the same collector that brought | into the 


post office. So both cases are proved. 


9. Conclusions and Future Research 


In this thesis, we have presented the local state approach to specification and 
verification techniques for both serial and parallel computations. As stated in the 
Introduction (Chapter 1), the work reported ‘here has made four major technical 
contributions. In concluding the thesis, we would like to first review these contributions — 


and then discuss their implications in the light of our projections for future research. 
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9.1 Summary and Conclusions 


- AS was demonstrated in Chapters 4 and 6, the local state approach provides 
powerful and convenient specification techniques for abstract data types with parallelism 
and side-effects with which previous techniques had failed to deal, | 

As the post office model in Chapter 8 illustrates, specification techniques based on 
local states enable us to describe the complex internal concurrent activities of a system, such 
as an Operating system or a multi-user data base system, in terms of the individual behavior 
of its subsystems and their mutual interaction. In order to express. the overall functional 
behavior of such systems (task specifications), the use of local states turns out to be not only 
useful, but crucial. In addition, however, we sometimes need to state temporal ordering 
constraints among events that are difficult to express in terms of the state changes of 
‘individual subsystems. For this purpose we have used an event-oriented specification 
languagelGreif-Hewitt75, Hewitt-Baker77] in which the ordering concepts in the underlying 
computation model can be talked about directly. Thus, with the complementary use of the 
ordering constraint statements, the effectiveness and versatility of the local state approach 
in specifying the behavior of systems with high internal concurrency is strengthened. 

To describe the states of individual data and procedural objects, we have 
developed. a system of notation called conceptual representations. Based on this notational 
device, we have presented a formalism for specification and verification. As was seen 
throughout the thesis, this formalism allows us to express states of individual ob jects 
directly and explicitly, Thus we believe that specifications written in our formalism are 
easy to understand and are less error-prone in their completeness and consistency, as 
compared with those written in other formalisms. Moreover, the separation of the states of 


an object from its identity makes it possible for conceptual representations to express 
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sharing structures among ob jects. and multiple instances of a class.of. ob jects. 

The ability of our formalism to express sharing structures and multiple class 
instantiation enabled us to develop a method for symbolic evaluation of programs written 
in object-oriented languages, which has not been attempted before. The developed method 
Is used for verification of serial computations and has suggested an approach to mechanical 


program analysis (Section 5.4, Chapter 5). 


9.2 F uture Research 


We have defined the states of an individual ob ject (actor) as equivalence classes on 
the past histories of messages (operations) sent to the object, Local states thus defined are 
expressed by conceptual representations which mathematically comprise sequences, 
collections and tuples. On the other hand, the state of an ob ject an be identified with a 
mathematical function which is obtained as a solution of the behavioral equations 
introduced in Section 6.4, Chapter 6. .So far the relationships between the above two 
interpretations of states have not been made Clear. We foresee that the investigation of 
these relations will reveal very rich mathematical structures and that, consequently, the 
properties of implementation invariants (Section. 5311, Chapter. 5) which we have left 


informal will be understood precisely. 


The techniques exemplified by the model of a simple post office can be applied to . 
the specif ication and verification of various distributed information processing ‘systems. 
Furthermore, the techniques used in this thesis have a direct-application in the area of 
busisiess automation. We expect that actor-like-procedural ob jects will enormously increase 


the flexibility and security of message and document systems by replacing "paper" forms 
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and letters and "paper" documents with “active” (procedural) counterparts that are sent to 
work stations in computer networks. Moreover, we can apply our techniques to the 
Specification and verification of object-oriented simulation and system description 


languages such as. the DELTA system[Holbaek-Hassen-et-al77). 


The verification process for parallel computations described in this thesis is 
informal. The formalization of such a process is desirable. For this purpose, a formal 
specif ication language in which both local states of objects and ordering constraints of 
events can be expressed in a coherent fashion must be developed, together with sound and 
powerful inference rules which are effective in dealing with the partial ordering of events. 
With such a formal system available, we will be able to construct practically useful software 
tools which assist us in the construction of parallel programs and distributed message 
passing systems. Various important properties, such as no-deadlock, no-starvation, and the 
property that a system meets its specifications, will be mechanically analyzed with such 


software tools. 
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Appendix | - Derivation of Axiom (5) 


The following axiom which was given in the algebraic specification of queues in 


Figure 2.6, Chapter 2. 


Axiom (5) 


if -IS-EMPTY(Q) a DEQUEUE(Q, A) = <B, Q> 
then DEQUEUE(ENQUEUE(Q, A)) = <B, ENQUEUE(Q’, A)> 


This is derived from the following. specification of queues based .on conceptual 


representations [which is identical to the one given in Figure 2.2, Chapter 2, except that the 


functionality of the operations is omitted]. 


(E1) 
(E2) 
(E3) 
(E4) 
(E5) 


(E6) 


(Derivation) 


CREATE-QUEUE() ----> . (QUEUE [)) 
ENQUEUE((QUEUE [8x}), A) ----> (QUEUE [1x A}) 
DEQUEUE((QUEUE [])) ----> ERROR 
DEQUEUE((QUEUE [A 5x])) “<--> <A, (QUEUE [1x])> 
IS-EMPTY((QUEUE [})) ====> TRUE 


TS-EMPTY((QUEUE [A §x])) <---> FALSE 


(1) s1S-EMPTY(Q) given as the premise of the axiom. | 


(2) DEQUEUE(Q) = <B, Q> given as the premise of the axiom. 


From (1) and (E6), Q must be of the form 


(QUEUE [front-element [rest)) 


From (2) and (E4), front-element = B and Q’ contains [frest], Thus (3) and (4) 


- Qi - 
hold. 
(3) Q = (QUEUE [B frest]) 
(4) Q’ = (QUEUE [frest]) 


(5) DEQUEUE(ENQUEUE(Q, A)) given in the consequence of the axiom. 
= DEQUEUE(ENQUEUE((QUEUE [B frest)), A) . | from (3). 
= DEQUEVE((QUEUE [B !rest A))) from (E2). 
= <B, (QUEUE [!rest A)))> _ jfrom (E4). 
= <B, ENQUEUE((QUEUE [frest]), A)> ;from (EQ). 
= <B, ENQUEUE(Q’, A)> | from (4). 


Hence, DEQUEUE(ENQUEUE(Q, A)) = <B, ENQUEUE(Q’, A)> (End of Derivation) 
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Appendix Il - Limits of Algebraic Specification 


To show the existence of abstract data types which cannot be expressed by a finite 
set of axioms in the algebraic approach, M. E. Majster[I977) gave a stack type which allows 
us to look at any stack elements by using a position information i. The functionality of this 


type is as follows. 


CREATE: = ---> stack ycreates an empty stack. 


PUSH: stack X item ---> stack or error 
tries to insert an item at the top. 
;if i is not pointing to the top, undefined 
;otherwise i points to the new top item. 


DOWN: stack ---> stack or error 
tries to increment i by one. 
if i already points to the bottom item, error. 


POP: stack ---> stack or error 
tries to remove the top item. 
if i is not pointing to the top, error 
;otherwise, i points to the new top item. 


READ: stack ---> stack or error 
tries to read the item pointed by i. 
)if stack is empty, error. 


RETURN: stack ---> stack or error 
itries to cause i to point to the top item. 
if stack is empty, error. 
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Unfortunately, the axioms for these operations cannot be characterized finitely. 
For example, we need infinitely many axioms expressed as follows. 
RETURN(DOWN)™(PUSH)"(ig yi) = (PUSH)"(i rely) 


for all m>O andm<n 


where PUSH"(iq,..i,) = PUSH(..PUSH(CREATE(), iy). in) 


This data type can be easily specified by using conceptual representations of the 


following form. 
(STACK (position: i)(itema: [...])) 


The (position:...) component keeps the position information and the conceptual sequence in 
the (items:...) represents stack elements. A specification based on the conceptual 


representations is given below. 


(1) CREATE() --=> (STACK (position: 1)(items: [)) 


(2) PUSHU(STACK (position: i)items: [4s])), I) 
if i= 1  ---> (STACK (position: i)(items: [I §s])) 
otherwise ---> ERROR 


(3) DOWN((STACK (position: i)(items: [4s})) 
if i <length[#s] ---> (STACK(position: i + 1)(items: [!s))) 
otherwise <---> ERROR 
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(4) POP((STACK (position: i)items: [!s})) 
ifi= i lands=([I frest] ---> (STACK (position: i)(items: [irest})) 


otherwise <---> ERROR 


(5) READUSTACK (position: ?){items: [])) <--> ERROR 


(6) READ(U(STACK (position: i)(items: (Ixl I 'x2))) --2 I 


where length[{'xil)=i-1 


(7) RETURNUSTACK (position: i){items: (#8))) 
ifs=[} <---> ERROR 


otherwise ---> (STACK (position: i)}litems: [!s])) 
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Appendix Ill ~ Recursion, Iteration and Loop Invariants 


The handling of recursive invocations of modules in symbolic evaluation has been 
illustrated in the example of empty-one-queue-into-another in Section 5.2.1, Chapter 5. In 
general, recursive invocations are treated as the same as ordinary invocations of modules. 
When a [recursive] invocation of a module M is encountered in symbolic evaluation, the 
contract of M is referred to and the specified results and postconditions are used to 
continue the symbolic evaluation after making sure that all the preconditions of M are 
satisfied. 

Iterations in implementations can be handled almost in the same way, because the 
iteration construct in PLASMA allows us to treat an iteration as a module. Thus if 
specifications of such modules are supplied, loops can be treated as ordinary modules. 

Another way of dealing with iterations is to rely on assertions which hold every 
time the control reaches the beginning point of a loop. Such assertions are called loop 
invariants or inductive assertions[Floyd67, Hoare69]. Since loop invariants are usually not 
derived from the process of symbolic evaluation, they must be supplied externally. 
Symbolic evaluation of the part of a code which follows such assertions is carried out under 
the assumption that the assertions hold in the situation corresponding to the beginning 


point of the loop. To illustrate this technique, we will consider a simple example. 
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Fig. IILi. An Iterative Version of empty-one-queuecinto-another 


(empty-one-queue-into~another-a = 
(=> [=qi =q2] 
(fq1 q2] => 
(loop = 
=> [=qql =qq2] 

*xk 

(rules (qql <= (dq:)) 

(= (exhausted:) 


~ Sexhausted-qqi ~ 
(done: [aqi aq2])) 
(=> [=front-of-qql =dequeued-qqi] 


fa S dequeved-qqi 2 
(qq2 <= (nq: front-of-qqi)) 
(loop <= [dequeved-qqi qq2j)) }))))) 


In Figure II1l, an iterative version of empty-one-queue-into-another-a is given. 


The loop invariant for loop which holds at the point where #s is placed in the code is 
[Bout $02) = [8x1 8x2] 


where xxi. and xx2 are the elements of the impure queues which are bound to qqi and qq2, 
respectively, and x1 and x2 are the elements of the impure queues bound to qi and q2, 


respectively. This invariant is expressed in our formalism as follows. 
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<loop-Invariant:  (8xxd Exx2) = [x1 $x2] 
where 


in Sit{[loop <= [QQ1 QQ2]]] 


(QQ1 is-a (/MPURE-QUEUE [!xx1])) 
(QQ2 is-a (JM PURE-QUEUE [!xx2))), 


in Sit([[ empty-one-queue-into-another-a <= [Q1 Q2]]]] 
(Qi is-a (JM PURE-QUEUE [!x1))) 
(Q2 is-a ([MPURE-QUEUE [1x2])) > 
Given the above invariant, it is easily demonstrated that the implementation in Figure III.1 
satisfies the contract for empty-one-queue-into-another given in Figure 5.5 in Chapter 5. 


The key point of the demonstration is that when the control reaches S the 


exhausted-qqi' 
impure queue QQ1 that qqi is bound to is empty, i.e. xx1 = []. Therefore, the elements of 
the impure queue 002 that qq2 is bound to, which are expressed as xx2, are equal to [§x1 
1x2] because [xxl !xx2] = [Ix1 !x2] (from the invariant), and xxl = [] imply xx2 = [x1 
§x2]. The rest of ‘the demonstration can be carried out almost in the same way as that for 


the recursive version shown in Section 5.2.1, Chapter 5. 
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Appendix IV - Convergence of empty-one-queue-into-another 


Most event specifications written in our specif ication language contain 
<caused-erent:...> OF <return:..> Clauses. As explained in Section 43.1, Chapter 4, the existence 
of these clauses in an event specification indicates that an event E stated in such a clause is 
required to take place. Thus, to verify an implementation against specifications, we have to 
demonstrate that the event E always takes place, as well as that the postconditions are 
satisfied. | 

As an example, let us consider the convergence of the implementation of 
empty-one-queve-into-another [hereafter empty) given in Figure 55 in Chapter 5. [The 
following discussion is based on the symbolic evaluation of the implementation presented in 
Section 5.2.1, Chapter 5.) For the demonstration of the convergence, we need to show that 
the control always reaches the situation reentry: provided that the two actors sent to 
emply are distinct and both are impure queue actors. 

If the impure queue bound to qi becomes empty during the recursive invocation of 
empty, S exhausted-qi ©2" be reached. Thus it is sufficient to show that the length of the 
impure queue eventually becomes zero. Since the length of the impure queue is an 
arbitrary non-negative integer when it arrives at empty for the first time, we need to show 
that its length decreases at its every subsequent arrival at empty. What has to be shown can 
be stated in our formalism as follows. 


(length-of(qi) in 5 -eceived-queues ) 
is-greater-than . (%)} 


( length-of(dequeve-qi) in Sgnqueued-q2 ) 


To show this, the situational tree produced by the symbolic evaluation of the 


implementation is examined. Length-of on impure queues is defined as 
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<property: length-of(Q) = length(x) 
where (Q is-a (IMPURE-QUEUE [!x])) > 
By using assertions about Qi and Q2 in conjunction with the binding information for qi 


' and dequeued-q1, we obtain the following facts. 


length-of(q1) = length(x1) in B received-queues’ 


length-of (dequeve-qi) = length(y) in B enqueved-q2 
Since x1 =[B fy] holds, the desired relation (*) is shown. 
Note that the precondition that Qi and Q2 are distinct actors was used in obtaining 


the assertion about the state of Qi in § 9: This precondition guarantees that [92 


enqueuecq 
= (nq:...)]] does not change the state of Qi, and hence that assertion could be inherited 


from § dequeued-qi 
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Appendix V - Another Specification of One-a-at-Time Serializers 


Another specification of one-at-a-time serializers is given as the following four 
event specifications. The first event specification is concerned with the creation of a 
one-at-a-time serializer. The second one describes the event where the serializer receives a 
request. A buck passer actor BP is created.and placed in the crowd. Note in (Case-1:...) 
clause that BP is sent to the resource R as the continuation of the message in the caused 
event. A reply from the resource is always sent to a buck passer BP. This is described in 
the third event specification. Then the buck passer sends the reply from the resource to the 
serializer G which created BP. The fourth event specification describes how the reply sent 


from the buck passer is handled by a serializer. 


<event: [ create-one-at-a-time <= RJ] 
<return: G* > 
<post-cond: (G is-a (ONE-AT-A-TIME (queue: (})(crowd: {})(resource: R))) >> 


<erent: [G <== M] 
where M = [request: RQ reply-to: C) 
(Case-]: 
<pre-cond: (G ts-a (ONE-AT-A-TIME (queue: [])(crowd: {})(resource: R))) > 
<nevt-cond: 
(G is-a (ONE-AT-A-TIME (queue: (]\crowd: {BP*})(resource: R))) 
(BP is-a (BUCK-PASSER (continuation: C)(serializer: G))) > 
<caused-events: [R <== [request: RQ reply-to: BPYJ >) 
(Case-2: 
<pre-cond: (G is-a (ONE-AT-A-TIME (queue: (§x)Mcrowd: {BP})}(resource: R))) > 
<nexvt-cond: (G is-a (ONK-AT-A-TIME (queue: [ix M])(crowd: {BP})(resource: R))) > 


<caused-events: I} >) 
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<event: [[BP <e= [reply: AJ] 
<pre-cond: (BP is-a (BUCK-PASSER (continuation: C)(serializer: G))) > 
<caused-event: [ G <== [reply: (buck: A (continuation: C) (buck-passer: BP))]]]>> 


<event: [G <== [reply: (buck: A (continuation: C) (buck-passer: BP)))] 

(Case-I: 
<pre-cond: (G is-a (ONE-AT-A-TIME (queue: [])(crowd: {BP})(resource: R))) > 
<next-cond: (G is-a (ONE-AT-A-TIME (queue: [])(crowd: {})(resource: R))) > 
<caused-events: [C <== [reply: A] >) 

(Case-2: 
<pre-cond: ‘ 

(G is-a (ONE-AT-A-TIME (queue: (WM §x})(crowd: {BP})(resource: R))) 
(WM = [request: RQ reply-to: CC]) > 
<next-cond: 
(G is-a (ONE-AT-A-TIME (queue: [1x])(crowd: {NBP*})(resource: R))) 
(NBP is-a (BUCK-PASSER (continuation: CC)(serializer: G)))) > 
<caused-events: { [C <== [reply: AJ] , [[R <e= [request: RQ reply-to: NBP)]] } >)> 
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